Как лучше всего настроить пользователей и разрешения для производственного веб-сервера, который использует git для развертывания на сервере?
Задний план
Запуск Ubuntu 12.04, у меня есть файлы обслуживания apache в /var/www так как www-data. У меня также было чистое репозиторий git в каталоге корневых пользователей, которое проверялось на /var/www/example.com в крючок после приема.
Это сработало нормально, но, учитывая, что это производственный сервер, я хотел усилить безопасность и удалить репо от пользователя root. Итак, я создал пользователя git и настроил репо в /home/git. Но теперь у меня есть проблемы с разрешениями из-за того, что один пользователь владеет репо, а другой - корневым веб-сайтом.
Я прочитал много форумов и руководств в Интернете. Большинство, похоже, просто используют пользователя root, у других проблемы с безопасностью хуже (например, предоставление www-data права на чтение репо). Я ищу идеи из реального опыта, потому что есть много способов сделать это.
Отметим, что обработчик post-receive делает больше, чем просто оформление заказа. Он также выполняет некоторые процессы сборки, такие как запуск Composer и некоторых других сценариев php, которые могут занять несколько минут.
Я пробовал несколько решений:
Я попытался добавить пользователя git в www-data group, а затем перерезать корневой каталог сети www-data на конце крючка. Здесь есть две проблемы. Во-первых, мне нужно изменить файл sudoers, и результаты, которые я получаю, оказываются неудачными. Во-вторых, в течение тех нескольких минут, пока работает ловушка, извлеченные файлы принадлежат git, а не www-data, поэтому пользователи на сайте могут получить ошибки чтения.
Я попытался поместить содержимое пост-приема в другой файл и выполнить его с помощью sudo. Опять же, это требует редактирования файлов sudoers, чтобы пользователь git мог выполнять sudo без пароля.
Или может случиться так, что оставить репо под пользователем root - меньшее зло, и я делаю все это напрасно.
Есть ли лучшее решение, которое я не пробовал?
Создайте новую группу и добавьте git и www-data пользователя в это. Затем настройте репозиторий git bare, чтобы всегда использовать группу, которую вы создали, в качестве gid для файлов репозитория. С новым дыхательным аппаратом вы делаете это вот так git init --shared=group. (Ссылка) Это позволит www-data аккаунт для чтения репозитория.
Обновите свои sudoers, чтобы разрешить git учетная запись для запуска команд как www-data без пароля.
# file: /etc/sudoers.d/gitpush
# permissions should be 0440
# git user is allowed to basically do anything as the www-data user
git ALL=(www-data) NOPASSWD: ALL
Тогда просто имейте post-receive сценарий sudo -u www-data для всех команд, необходимых для выполнения проверки / исправлений.
В стандартном модуле mod_php /var/www/example.com может принадлежать пользователю git, а любые файлы / папки, которые должны быть доступны для записи php, должны принадлежать www-data (или иметь разрешения 666/777). В этом случае один виртуальный хост может записывать другие файлы виртуального хоста.
Или: если вы используете mod_php, вы можете добавить, например, mod_ruid2 в Apache, а затем запускать каждый виртуальный хост с его собственным uid. В данном случае это будет пользователь git. Или php-fpm, если вы предпочитаете fastcgi, например установку, и каждый виртуальный хост имеет собственный пул php-fpm. Таким образом, каждый виртуальный хост может записывать собственные файлы, но не файлы с других виртуальных хостов.
Зависит от того, какой способ вы предпочитаете.
Я думаю, что есть лучший способ справиться с этим сценарием.
Сначала я бы переключился с простого git к чему-то с контролем доступа на основе ролей (RBAC), например gitolite.
Я бы также рекомендовал прочитать этот статья, описывающая рабочий процесс, очень похожий на тот, который вам нужен.
Чтобы реализовать решение, соответствующее вашим требованиям, необходимо выполнить следующие шаги:
gitoliteНа мой взгляд, преимуществ много:
post-update скрипты перехватаgitрепозиторий, поэтому аудит становится простой задачей (git log и git blame)