Как настроить разрешения в Linux, чтобы два пользователя могли обновить одну и ту же рабочую копию SVN на сервере?

Question

На моем сервере установлены Subversion и Apache, и веб-каталог Apache также является рабочей копией Subversion. Причина этого в том, что простая команда svn update /server/staging развернет последний источник на промежуточном сервере.

Общий веб-каталог Apache: /server/staging - (Это рабочая копия SVN.)

У меня есть два пользователя на моем сервере, 'richard' и 'austin'. Они оба являются членами группы разработчиков. Я рекурсивно устанавливаю разрешения для каталога / server для richard: developers, используя "sudo chown -R richard: developers /server".

Затем я установил права на чтение, запись и выполнение как для «richard», так и для группы «developers».

Так что, конечно, теперь 'austin' сможет использовать команду svn update /server/staging? Однако, когда он пытается, он получает ошибку:

svn: Can't open file '/server/staging/.svn/lock': Permission denied

Если я рекурсивно изменю владельца / server на austin: developers, он может выполнить команду просто отлично, но тогда 'richard' не сможет.

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

/usr/bin/svn update /server/staging

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

Любая помощь приветствуется!

Answer 1

Идентификатор группы каталогов

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

Этот атрибут полезен, когда нескольким пользователям необходим доступ к определенным файлам. Если пользователи работают в каталоге с установленным атрибутом setgid, то любые файлы, созданные в каталоге любым из пользователей, будут иметь разрешение группы. Например, администратор может создать группу с именем spcprj и добавить пользователей Kathy и Mark в группу spcprj. Каталог spcprjdir может быть создан с установленным битом GID и Kathy and Mark, хотя в разных основных группах он может работать в этом каталоге и иметь полный доступ ко всем файлам в этом каталоге, но при этом не может иметь доступ к файлам в основной группе друг друга. .

Следующая команда установит бит GID в каталоге:

chmod g+s spcprjdir

Список каталогов каталога "spcprjdir":

drwxrwsr-x 2 kathy spcprj 1674 Sep 17 1999 spcprjdir

"s" вместо бита выполнения в разрешениях группы заставляет все файлы, записанные в каталоге "spcprjdir", принадлежать группе "spcprj".

edit: source = Файлы Linux и права доступа к файлам

Answer 2

Я использую WebDAV - все обновления и фиксации SVN обрабатываются через Apache, и у меня никогда не возникало таких проблем.

Answer 3

в вашем репозитории SVN вы можете найти каталог 'conf', в котором вы устанавливаете разрешения. у вас там 3 файла:

• AuthZ
• PASSWD
• svnserve.conf

Вы задаете в файле authz, какие пользователи имеют какие виды доступа, для пользователя или для группы. Вы устанавливаете группы там, группы SVN, а не группы пользователей Linux (хэшированные строки являются комментариями):

[groups]
# harry_and_sally = harry,sally
projectgroup = richard,austin

# [/foo/bar]
# harry = rw  -- user harry has read/write access
# * =  -- everybody have no access

# [repository:/baz/fuz]
# @harry_and_sally = rw  -- harry_and_sally group members have read/write access
# * = r  -- everyone has read access

[/server/staging]
@projectgroup = rw
* = r

обойдите этот пример и настройте свой конфиг. в файле 'passwd' вы устанавливаете пароли пользователей. выполнение

cat passwd

вы получите закомментированный файл с объяснением, как его настроить.

Answer 4

Я бы настроил svnserve, который является простым сервером Subversion, использующим протокол svn://. Вы можете настроить его так, чтобы он работал под собственной учетной записью пользователя, тогда доступ к хранилищу мог получить только этот один пользователь. Этот пользователь может затем иметь правильные привилегии для запуска svn update /server/staging на ловушке после фиксации.