Меня попросили создать общее веб-пространство на веб-сервере нашего отдела, к которому могут получить доступ несколько человек и на котором могут выполняться сценарии CGI или PHP. Люди, обслуживающие веб-пространство, могут решить использовать его для отправки файлов, что будет означать, что им потребуется доступ к любым файлам, созданным сценариями. Мы запускаем Apache в Scientific Linux 6.
Поскольку нескольким людям требуется доступ для записи в веб-пространство, наш стандартный подход заключается в создании группы, к которой принадлежат все соответствующие люди, а затем для установки разрешений для каталогов в веб-пространстве на g+ws. suexec недоволен тем, что файлы доступны для групповой записи, и отказывается их запускать.
Как мы можем это настроить и убедиться, что любые сценарии запускаются под учетной записью, которая отличается от основной учетной записи apache (и отличается от любого из пользователей, которые не в группе для веб-пространства)? По причинам подотчетности (и другим) я бы предпочел не создавать общую учетную запись, которую различные люди должны будут использовать для поддержки этого веб-пространства.
Для более подробного контекста, вот как мы сейчас настроены: у нас есть пользователи, чьи домашние каталоги находятся в NFS и при необходимости автоматически монтируются. Большинство людей просто используют свое личное веб-пространство, доступное через mod_userdir. В прошлом мы отправляли несколько запросов на совместное веб-пространство, создавая дополнительные автоматически подключенные каталоги на сервере NFS, которые не привязаны к конкретным учетным записям, но для которых настроено групповое владение для облегчения доступа для нескольких учетных записей. До сих пор эти общие пространства содержали только статический контент (и мы доверяли вовлеченным людям не запускать из них скрипты), поэтому нам никогда раньше не приходилось решать какие-либо проблемы, связанные с suexec, для такого рода пространств.
редактировать: Обратите внимание, что пользователям может потребоваться доступ к файлам, созданным сценариями.
Чтобы обеспечить подотчетность в этом контексте и при этом обеспечить правильное владение и разрешения для опубликованного контента, я использую слегка измененную версию рабочего процесса, описанного в этот статья.
Вот как я реализовал, обратите внимание, что большинство частей можно заменить:
#!/bin/sh
sudo /usr/local/sbin/publisher-hub2live
exit 0
Скрипт не доступен напрямую неавторизованным пользователям:
# ls -lrt /usr/local/sbin/publisher-hub2live
-rwx------. 1 root root 400 Oct 12 2012 /usr/local/sbin/publisher-hub2live
Отсюда судорула:
Defaults:git !requiretty
git Host_Alias = (root) NOPASSWD: /usr/local/sbin/publisher-hub2live
Заменить git с фактическим владельцем репозиториев.
Содержимое скрипта издателя работает здесь "волшебно" (упрощенная версия):
#!/bin/sh
echo
echo "**** Pulling changes into Live [Hub's post-update hook]"
echo
cd /path/to/live/repo || exit
umask 0022
unset GIT_DIR
git pull hub master
chown -R root:root /path/to/live/repo
find /path/to/live/repo/ -type d | xargs chmod u=rwx,go+rx
find /path/to/live/repo/ -type f | xargs chmod u=rw,go+r
restorecon -v -R /path/to/live/repo
exec git update-server-info
exit 0
Ваши потребности могут различаться в зависимости от прав владельца, группы, DAC и MAC, но рабочий процесс остается прежним.