Does CiviCRM allow us to declare which directories are writable, allowing the rest to be locked-down?

CiviCRM core seems to be consistent in only writing to a files directory. Until recently, however, it attempted to write to the extensions directory to store extension updates. It's unclear if CiviCRM enforces this for extensions. I've heard that some extensions will write to directories outside of the files (but I haven't been able to confirm this). If that's the case then it will conflict with PAAS that only allow certain directories to be writable.

It seems like we have to find a meeting point between the CMS and CRM expectations. (This comment is relevant to #3 (moved) also.)

CiviCRM

• Extensions - some people prefer these treated as code, some people prefer them treated as webserver-writable content
• Supporting these two modes of operation is mostly there - CiviCRM lets you set Extensions directory to www-writable location or not
• Extensions directory is location for both CiviCRM's cached data (which could be stored in a different location, including not to disk) and for executable code
• If cache location is not writable, CiviCRM shows warnings
• Media - CiviCRM permits upload of media in a few different ways, sometimes this is sensitive and sometimes not
• CiviCRM uses the same base path for all uploaded media associated with an Entity, where some data may be sensitive and some may not be
• Ability to set privacy per-field would be great?

Drupal / Backdrop

• Drupal expects sites to write data to the public or private files paths.
• These are sites/<SITE>/files and sites/<SITE>/private per default (D7)
• Private files can be outside the webroot, we should presume direct access to private files is not supported
• Drupal prefers to use stream wrappers to interact with files, rather than absolute paths. Hosting platforms might place files in a location not accessible via "traditional" path references.

WordPress

• Plugins should write data to WordPress Uploads folder
• Default path is wp-content/uploads (this can be modified)
• How does WordPress handle private files? Can we prevent their access

See: https://codex.wordpress.org/Hardening_WordPress#WP-Content.2FUploads

Joomla

...?

(had to run off before finishing this comment!

On systems which have a concept of "private" data directory, it would be great to move templates_c and ConfigAndLog over there. (But do this without breaking shit.)

Regarding the cache for CRM_Extension_Browser, I'd be +1 for moving it out of the filesystem. Use a SqlGroup instead.

Regarding the extensions folder, the intent is that you can set the permission on the extensions folder as you please. If it's writable, then you can do downloads through the GUI. If it's not writeable, then you can't. The warning that comes to my mind is this one -- which seems appropriate in context (although the wording could be improved):

But as @xurizaemon points out, there do seem to be other warnings, and these should probably be a bit less noisy:

Instead of a red error, show a blue suggestion, eg: "Extensions Downloads: Many extensions are available for CiviCRM. If you would like to download extensions in the web UI, please make the folder /var/foo writable."

added type:proposal label

added triaged label

added needs:concept approval label

These thoughts need to be turned into discete, specific tasks that @tiotsop, a GSoC student, can set to work on.

Gleaning over this I think these are some discrete tasks from above:

• move the cache for CRM_Extension_Browser out of the filesystem and use a SqlGroup instead.
• update the wording on the message when Extensions directory is set to unwriteable (Make it clear that the admin has disabled writing to the directory in the settings file. And that this is by design.)
• Instead of a red error, show a blue suggestion, eg: "Extensions Downloads: Many extensions are available for CiviCRM. If you would like to download extensions in the web UI, please make the folder /var/foo writable."

The only other idea is already addressed in #3 (moved)

Thanks, @herbdool ! These are great specific tasks.

See this PR https://github.com/civicrm/civicrm-core/pull/11895 which goes some way (maybe all the way?) to implementing the improved wording of the extension directory messages.

Thanks @michaelmcandrew that seems to go most of the way.

The last remaining piece for this issue is this: move the cache for CRM_Extension_Browser out of the filesystem and use a SqlGroup instead.

I took a look at the cache. Seems that in terms of this issue it was fixed a year ago. It's no longer saving to the extension directory, but to the upload directory which is always writable. https://github.com/civicrm/civicrm-core/commit/c5bf60d572c9ed167fb86d642d60cce7688bed26

I don't think there's any urgency to move it out of the filesystem entirely now, so I think I'll close this issue.

closed

mentioned in issue #17 (moved)

moved to core#3535 (closed)

mentioned in issue core#3542 (closed)