Защита проверок Subversion для файлов конфигурации системы

Question

Мы уже давно используем subversion для контроля версий наших программных проектов. Так как мы разрабатываем на python, я недавно начал использовать subversion для развертывания рабочих копий сайтов. Когда сайт обновляется в репо, на сервере вызывается ловушка post-commit, и она вносит изменения в живые сайты.

Продолжая в том же духе, я видел ссылки на других людей, использующих контроль версий для своих скриптов конфигурации сервера. Мы работаем с Ubuntu 9.04, и я могу представить себе утилиту наличия (например) всех / etc / versioned, чтобы, если я испорчу конфигурацию apache или установлю что-то, что скрывает какую-то существующую конфигурацию, я мог бы просто восстановить из резервной копии .

Мой вопрос (и проблема) заключается в том, что в настоящее время все наши разработчики имеют доступ ко всему нашему хранилищу subversion. Если я начинаю вводить конфиденциальную конфигурацию системы, думаю, что имеет смысл ограничить доступ, но я не знаю, как это сделать. Как только я получу все файлы в репо, как мне управлять оформлением заказа и регистрацией? Вносить изменения локально, а затем отправить на сервер? Модифицировать сервер и затем нажать на репо? Наш сервер Subversion - это другой физический компьютер, поэтому я не могу использовать проверку локальных файлов. Как я должен обращаться с безопасностью для этого? SSH без пароля?

Кроме того, о каких других проблемах безопасности я должен знать в такой ситуации? Я знаю, что в каталоге .svn хранится много информации. Буду ли я подвергать свой сервер риску чего-то подобного? Является ли сама по себе Subversion достаточно безопасной, чтобы сделать это возможным?

Кроме того, правильно ли Subversion сохраняет и восстанавливает права доступа к файлам и права доступа?

Answer 1

В ответ на последний вопрос, нет, subversion изначально не поддерживает права доступа к файлам, владельца и т. Д. Вы можете проверить asvn, который, как известно, хранит их, но некоторое время не обновлялся.

Лучшим вариантом, вероятно, является сценарий развертывания, который просматривает и модифицирует каждый файл с соответствующими разрешениями, владельцем и т. Д. После развертывания.

Answer 2

Если вы обращаетесь к своему хранилищу subversion по HTTP (например, через Apache), то вы можете использовать Apache для управления доступом к различным ресурсам / фиксации.

Мы делаем что-то подобное, чтобы ограничить коммиты в нашем хранилище на основе разрешений LDAP.

Подробнее см. mod_authz_svn и mod_dav_svn .

Answer 3

Исключая системные каталоги из загрузки или доступа для всех, кто использует систему авторизации SVN, вы можете настроить файл аутентификации или настроить доступ LDAP, если у вас настроен сервер LDAP, и настроить SVN через SSH для повышения безопасности.

Я бы также рассмотрел вопрос о сохранении конфигурации системы в другом хранилище и заблокировал ее от нежелательного доступа. В этой ситуации лучше протестировать изменения локально, а затем загрузить их в репозиторий, поэтому, если вы все испортили, вы еще не сделали неправильную ревизию.

В любом случае, не очень безопасно хранить системные файлы в системе управления версиями, однако, рассмотрите следующий сценарий: вы испортили конфигурацию и сделали свою машину не загружаемой, вы сохранили испорченную конфигурацию в SVN, теперь вам нужно:

1. физический доступ к затянутой машине
2. восстановление через svn с использованием загружаемой операционной системы
3. уничтожить ревизию, вызвавшую проблему

Конечно, если вы справитесь со всеми этими трудностями, это может быть решением, но не самым безопасным. Если вам действительно необходимо постоянно обновлять конфигурацию вашей системы, вам лучше связать файлы, которые вы обновляете, из другого каталога, например:

/etc/apache -> /usr/local/etc/apache

и вместо этого вы улучшите их версию, сохраняя / etc в чистоте

В качестве последнего соображения: вы НЕ думаете о включении этого сервера / репозитория в Интернет. (это был не вопрос: D)