对于几个Drupal站点，我和我的同事（用于演示目的alice和bob ）负责维护这些安装。 我们都有一个SSH帐户login到服务器（带有ID文件，没有密码）。 但是，我们不是服务器pipe理员，并且没有sudo权限。
在drupal.org有一个文件权限的详细页面 ，我也读serverfault上的这个问题 。 但是我不能为我们的情况拿出一个安全的系统。
用户当前设置：
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)
据我所知，Apache用户（ www-data ）不应该有写访问它将执行的文件。 根据Alice或Bob是否安装了系统，文件所有者对于系统文件是不同的，但是组被设置为webteam并且权限是664，所以所有者和组都可以写入，Apache只能读取文件：
-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
在Drupal中（也可能在其他CMS中），Drupal保存caching文件和用户上传时，有一个特殊的文件夹（默认为./sites/default/files ）。 所以这个文件夹必须有rw的Apache。 目前看起来像这样（ files是公用文件，允许盗链， secure是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
在这种情况下，爱丽丝创build了网站，因此是目录的所有者。 www-data被允许在那里做所有事情以及它是必需的（如前所述）。 鲍勃有权访问这些目录以及他是www-data成员。
问题1： 是否有更好的方式来分发权限，你看到这个设置有什么（安全）缺陷？
当使用drush工具更新模块和/或Drupal内核时，会出现另一个问题。 drush使用执行drush的用户，并设置Drupalbuild议的权限。 第一个文件（index / update.php）看起来像这样在drush被执行之后：
-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
问题很明显，鲍勃不能再写或删除这些文件。 另外，他不能在该安装上运行（它会失败，并有权限问题）。
问题2： 什么是最好的方法来避免这种情况，或在运行后drush ？
我们想到的第一个select是让Alice和Bob用来login服务器的单个用户（例如webteam ）。 但个人而言，我更喜欢有我自己的主目录和我自己的.bash_rc文件自定义提示和别名。 其次，由于drush已经通过shell脚本执行了，我们可以在运行后（重新）设置文件权限。 也许还有更好的办法？
我们所做的是将代码签出到Web服务器的DocumentRoot之外的目录。 然后，我们安装并更新脚本来修改文件/目录，并将它们rsync同步到Web服务器的DocumentRoot。 在执行rsync的同时，我们还排除了我们不希望在生产服务器上的某些文件/目录（例如xmlrpc.php，sites / all / modules / simpletest）。
基本上所有文件都是440，所有的目录是550，除了../sites/$SITE/files目录是770之外，所有apache：apache都是owner：group。
我们确实授予sudo给我们的pipe理员，当使用drush时，我们执行如下操作：
sudo -u apache drush ...
希望这可以帮助。
PS
如果您还没有这样做，您可能需要将其交给drupal.stackexchange.com。