对于几个 Drupal 站点，我和我的同事（出于演示目的alice和bob）负责维护这些安装。我们都有一个 SSH 帐户来登录服务器（使用 ID 文件，无需密码）。但是，我们不是服务器管理员，也没有 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 中也是如此），有一个特殊文件夹（默认情况下为./sites/default/files），Drupal 在其中保存缓存文件和用户上传。因此，对于 Apache，此文件夹必须具有 rw 权限。目前它看起来像这样（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
在这种情况下，Alice 创建了该网站，因此是目录的所有者。www-data被允许在其中执行所有操作以及所需的操作（如前所述）。Bob 确实有权访问这些目录，因为他是 的成员www-data。
问题 1:有没有更好的方法来分配权限，您是否发现此设置存在任何（安全）缺陷？
当使用该drush工具更新模块和/或 Drupal 核心时，会出现另一个问题。drush使用执行的用户drush并按照 Drupal 的建议设置权限。Alicedrush执行后，第一个文件 (index/update.php) 如下所示：
-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
问题很明显，Bob 无法再写入或删除这些文件。此外，他无法drush在该安装上运行（它会因权限问题而失败）。
问题2：避免这种情况或在drush运行后纠正它的最佳方法是什么？
我们想到的第一个选择是让webteamAlice 和 Bob 都使用单个用户（例如）登录服务器。但就我个人而言，我更喜欢拥有自己的主目录和.bash_rc带有自定义提示和别名的文件。其次，由于drush已经通过 shell 脚本执行，我们可以在运行后（重新）设置文件权限drush。也许还有更好的方法？
答案1
我们所做的是将代码签出到 Web 服务器的 DocumentRoot 之外的目录中。然后我们安装和更新脚本，对文件/目录进行 chmod 并将它们 rsync 到 Web 服务器的 DocumentRoot。我们还在执行 rsync 时 --exclude 了我们不希望在生产服务器上使用的某些文件/目录（例如 xmlrpc.php、sites/all/modules/simpletest）。
基本上所有文件都是 440，所有目录都是 550，但 ../sites/$SITE/files 目录除外，它们是 770，所有 apache:apache 均为所有者：组。
我们确实向管理员授予 sudo 权限，并且在使用 drush 时我们执行以下操作：
sudo -u apache drush ...
希望这可以帮助。
附言
如果您还没有这样做，您可能想要交叉发布到 drupal.stackexchange.com。