CiviCRM does not have permission to write temp files

Question

Two users are trying to access the temp files (where, for instance, the compiled templates are stored): www-data (when it's accessed from the website) and the sysadmin that run drush commands

By default, all these temporary files can only modified by the user that created it, so sometimes it's the sysadmin, sometimes it's the webserver user

Is there a way so all the temp files can be created/modified/deleted by only the admin user(s) and www-data?

One possible fix is a patch on drush, so it uses a separate templates_c folder than the one used by www-data. Could you test if it works in your environment/workflow?

https://github.com/civicrm/civicrm-drupal/pull/286

Answer 1

There's no single perfect solution to this, but there are several adequate solutions. To highlight some trade-offs among the approaches raised so far:

• For each security principal, use separate data-directories (like bgm's answer).
  • Pro: Portable -- works in many different environments. Doesn't require any special tools or root permissions.
  • Con: Only works when data can be split apart by user. For example, it could potentially work for logs/caches (because they don't really need to be shared) but is more problematic for uploads/attachments (because both users should have read/write on the same objects).
• Create a cronjob or daemon to adjust permissions (like Chris's answer)
  • Pro: Portable -- you can design the daemon or cronjob to build on the traditional POSIX UGO/RWX triplets. Works with all data (logs/caches/attachments).
  • Con: Requires installing/running a new root-permissioned service. Watch out for symlinks/hardlinks.
• Use the operating system's ACL features (like amp's linuxAcl and osxAcl policies)
  • Pro: Works with all data (logs/caches/attachments). Doesn't require daemon or regularly running as root.
  • Con: Not standardized -- technical steps depend on the environment (OS/distro/filesystem). Sometimes applications try to be clever and override the permissions -- which breaks ACLs for specific files/use-cases.
  • (Note: amp tries to abstract this, but as with any abstraction, it's probably not worth the overhead unless you buy into the general vision.)

Answer 2

Setting directories group-setuid might get you part of the way (with chmod g+ws templates_c), but maybe we should consider something like this in the CiviCRM drush module?:

$config = CRM_Core_Config::singleton( );
$config->configAndLogDir = $config->configAndLogDir . 'drush/';
$config->templateCompileDir = $config->templateCompileDir . 'drush/';

i.e. create templates in a sub-directory of templates_c/drush/, this way the web server (www-data) will not have trouble writing in the templates/logs later on.

This is what Aegir did for a long time, but due to a regression it has not been working for a while and since then I run into that issue as well.

Answer 3

Tim describes a solution based on linux ACL:

https://github.com/totten/amp/blob/master/doc/perm.md

But it requires amp, that I (might be wrongly) see a dev only tool. Does someone use something like that in production?

Answer 4

Our solution to mixed access to CiviCRM's cache files (and other situations where permissions issues arose) has been a daemon which monitors filesystem entries and "corrects" permissions immediately on file creation/modification.

• Enforced on Github

There are still some issues with this approach (eg issue linked in comment on bgm's answer), but it seems to work out better than just relying on setgid (which I'd hope could be a complete solution).

I'm still a bit unsure of our taking this route - I'd prefer for UNIX permissions to work for people! They are simple and well-tested after all ... - but at least it's no longer a support headache :)