CiviCRM Community Forums (archive)

= Policy Level =

I think it's a good idea to set a default.

The issue of a default is potentially a proxy-battle for a different policy issue, but I think it's better to call that out as a separate issue. The issue is the "W^X" ("writable XOR executable") principle: it should be impossible for an application to write executable code. W^X is good from a security perspective because it makes it harder to exploit vulnerabilities, but (for PHP web-apps) it is diametrically opposed to in-app/web-based updates -- in-app updates are good from a security perspective because they make one less likely to run old/insecure code. Determining which is better for a particular site requires a hard look at the time+skills available for administration.

The current default (without any extension folder) is basically "W^X==yes, in-app-dl==no". Setting a default folder (without any other steps) would change that to "W^X==no, in-app-dl==yes". For anyone with a strong preference between W^X and in-app-dl, changing the default path is an opportunity to re-negotiate W^X/in-app-dl.

However, I think W^X should be a separate issue from the question of a default extension path. Setting a default path saves several steps for everyone -- regardless of whether one prefers CLI-downloads (W^X-compliant) or web-based downloads (not-W^X-compliant). Ideally, toggling the preferred policy should only require one small step -- disable write-access if you want W^X, enable write-access if you want web-based downloads. There should be no need to setup extra options for the specific paths/URLs.

= Implementation level =

During the 4.3 cycle, I spent some time trying to implement a default extension dir and had trouble getting my head around the code for default directories. There's a mismatch: mentally, we have a civicrm data folder (e.g. "sites/default/files/civicrm" in Drupal) and we put various things underneath (uploads, ConfigAndLog, etc), but formally that folder does not exist -- making new things in there requires a mix of guess-work and luck.

I actually think it would be better to remove the "extensionDir/extensionUrl" settings entirely and instead hard-code a path (in a CMS-sensitive way). A few reasons:

• We don't have to deal with the weirdness of how Civi manages data folders.
• After the initial migration, it's easier to document+support.

But it would require us to "bite the bullet" by (a) picking a standard and (b) requiring folks to migrate during upgrade.

The issue of a default is potentially a proxy-battle for a different policy issue, but I think it's better to call that out as a separate issue. The issue is the "W^X" ("writable XOR executable") principle: it should be impossible for an application to write executable code.

I try on my servers to implement that, or at least to disable execution of .php files directly from the web (assuming the folder is web accessible in the first place, eg for extensions)

I don't think it's possible to be properly Y^X, eg
- template_c directory that has to be writable, no matter what policy, we are a fair bit away or W^X anyway
- the extension folder not W (it has a cache there, or at least complains/crashes if not writeable).

Lastly, because you need to set up the folder via the web interface and that you tend to do that when you want to install a new extension (as opposed as during the initial setup), it's likely that it's a power user with either no ssh access or not enough understanding of the security issues nor willingness to investigate because right now, she's just trying to install extension X and the "directory issue is a bug on the way and 'fixed' by putting the first path that comes to mind")

Ideally, toggling the preferred policy should only require one small step -- disable write-access if you want W^X, enable write-access if you want web-based downloads. There should be no need to setup extra options for the specific paths/URLs.

+1

I actually think it would be better to remove the "extensionDir/extensionUrl" settings entirely and instead hard-code a path (in a CMS-sensitive way). A few reasons:

Would it be more complex to fix the root cause and explicitly have a civicrm data folder (and the only one coded as absolute path) and get all the others for log+upload+extension as relative to that?

But it would require us to "bite the bullet" by (a) picking a standard and (b) requiring folks to migrate during upgrade.

picking a standard seems to be the biggest issue so far

X+