Secure permissions setup for Drupal website with multiple maintainers

Question

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?

Answer 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.