Для нескольких сайтов Drupal я и мой коллега (в демонстрационных целях alice и bob) несут ответственность за поддержание этих установок. У нас обоих есть учетная запись SSH для входа на сервер (с файлом идентификатора, без пароля). Однако мы не являемся администраторами серверов и не имеем прав или разрешений 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) не должен иметь доступа на запись к файлам, которые он будет выполнять. В зависимости от того, установили ли систему Алиса или Боб, владелец файла для системных файлов разный, но для группы установлено значение 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 сохраняет файлы кеша и загрузки пользователей. Так что в этой папке должен быть 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
В этом случае Алиса создала веб-сайт и, следовательно, является владельцем каталогов. www-data разрешено делать там все, что требуется (как упоминалось ранее). У Боба есть доступ к этим каталогам, а также он является членом www-data.
Вопрос 1: Есть ли лучший способ распределить разрешения, видите ли вы какие-либо недостатки (безопасности) в этой настройке?
При использовании drush инструмент для обновления модулей и / или ядра Drupal, возникает другая проблема. drush использует пользователя, который выполняет drush а также устанавливает разрешение в соответствии с рекомендациями Drupal. Первые файлы (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
Проблема ясна, Боб больше не может записывать или удалять эти файлы. Кроме того, он не может бежать drush в этой установке (это не приведет к проблемам с разрешениями).
Вопрос 2: Как лучше этого избежать или выправить после drush побежал?
Первый вариант, о котором мы думали, - это иметь одного пользователя (например, webteam), которые Алиса и Боб используют для входа на сервер. Но лично я предпочитаю иметь свой домашний каталог и свой собственный .bash_rc файл с настраиваемой подсказкой и псевдонимами. Во-вторых, поскольку drush уже выполняется через сценарий оболочки, мы можем (повторно) установить права доступа к файлу после drush бежит. Может есть способ получше?
Что мы делаем, так это извлекаем код в каталог за пределами DocumentRoot веб-сервера. Затем у нас есть сценарии установки и обновления, которые изменяют файлы / каталоги и синхронизируют их с DocumentRoot веб-сервера. Мы также исключаем определенные файлы / каталоги, которые нам не нужны на наших производственных серверах (например, xmlrpc.php, sites / all / modules / simpletest) при выполнении rsync.
По сути, все файлы имеют размер 440, а все каталоги - 550, за исключением каталогов ../sites/$SITE/files, которые имеют номер 770, все apache: apache для owner: group.
Мы предоставляем sudo нашим администраторам, и при использовании drush мы выполняем следующее:
sudo -u apache drush ...
Надеюсь это поможет.
P.S.
Возможно, вы захотите сделать перекрестную публикацию на drupal.stackexchange.com, если вы еще этого не сделали.