2

For several Drupal sites a colleague of mine and I (for demonstration purposes alice and bob) are responsible for maintaining these installations. We both have an SSH account to log into the server (with ID file, no password). However, we are not server administrators and have no sudo rights or permissions.

On drupal.org there is a detailled page on file permissions and I also read this question on serverfault. But I can't come up with are secure system for our situation.

Current setup of users:

uid=16(alice)    gid=1001(webteam) groups=1001(webteam),32(www-data)
uid=17(bob)      gid=1001(webteam) groups=1001(webteam),32(www-data)
uid=32(www-data) gid=32(www-data)  groups=32(www-data)

From what I understand, the Apache user (www-data) shouldn't have write access to files which it will execute. Depending on whether Alice or Bob have installed the system, file owner is different for system files, but group is set to webteam and permissions are 664, so both owner and group can write, Apache can only read the file:

-rw-rw-r--+   1 alice  webteam    529 Oct 15 16:36 index.php 
-rw-rw-r--+   1 bob    webteam   3847 Sep 28 12:03 update.php 

In Drupal (as probably in other CMS as well), there is a special folder (by default at ./sites/default/files) where Drupal saves cache files and user uploads. So this folder must have rw for Apache. Currently it looks like this (files is for public files, hotlinking allowed; secure is for the private file system in Drupal):

drwxrwsr-x+ 12 alice www-data  4096 Oct 29 11:43 files
drwxrwsr-x+  3 alice www-data 20480 Oct 24 15:27 secure

In this case, Alice created the website and thus is owner of the directories. www-data is allowed to do everything in there as well as it is required (as mentioned before). Bob does have access to these directories as well as he is member of www-data.

Question 1: Is there a better way to distribute permissions, do you see any (security) flaws with this setup?

When using the drush tool to update modules and/or Drupal core, another problem arises. drush uses the user who executes drush and also sets the permission as advised by Drupal. The first files (index/update.php) look like this after drush was executed by Alice:

-rw-r--r--+   1 alice  webteam    529 Oct 15 16:36 index.php 
-rw-r--r--+   1 alice  webteam   3847 Sep 28 12:03 update.php

The problem is clear, Bob can no longer write or delete these files. Also, he can't run drush on that installation (it will fail with permissions issues).

Question 2: What is the best way to avoid this or to straighten it after drush ran?

First option we thought of would be to have a single user (e.g. webteam) which both Alice and Bob use to log into the server. But personally, I prefer to have my own home directory and my own .bash_rc file with custom prompt and aliases. Second, since drush is already executed through a shell script, we could (re)set the file permissions after drush runs. Maybe there's an even better way?

  • We deploy Drupal with capistrano. To the extent drush is ever used, it's mostly on the developers' machines, and rarely is this an issue in production. – Michael Hampton Oct 30 '14 at 16:52
1

What we do is we checkout the code to a directory outside of the webserver's DocumentRoot. Then we have install and update scripts that chmod the files/directories and rsync them over to the webserver's DocumentRoot. We also --exclude certain files/directories that we don't want on our production servers (e.g. xmlrpc.php, sites/all/modules/simpletest) while doing the rsync.

Essentially all files are 440 and all directories are 550 with the exception of the ../sites/$SITE/files directories which are 770, all apache:apache for owner:group.

We do grant sudo to our admins and when using drush we execute like so:

sudo -u apache drush ...

Hope this helps.

P.S.

You might want to cross-post to drupal.stackexchange.com if you haven't done so already.

  • Thank you for sharing your way. Unfortunately, we do not have a reasonable deploy system in place (yet), so Alice and Bob need to be able to change files directly. Other than that, it looks like a secure way to go but I am no sysadmin and hence not really able to evaluate (thus my questions). Regarding cross-posting, my understanding is that this should not be encouraged and even though we are working almost exclusively with Drupal, this question seems to apply to other environments/CMS as well. – Paul Oct 30 '14 at 15:10
  • Well, I commend you for seeking out security best practices but the bottom line is that you should be using version control and you should be using install/update scripts. – HTTP500 Oct 30 '14 at 17:24

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.