Subversion создает каталоги ревизий со слишком строгими разрешениями

Question

Этим утром я попытался зафиксировать ревизию в Subversion и обнаружил, что внезапно у меня не было разрешения сделать это.

Can't move '/svn/db/txn-protorevs/21000-ga9.rev' to '/svn/db/revs/21/21001':
Permission Denied

Глядя на каталог revs, я заметил, что кто-то зафиксировал 21000-ю ревизию, и по какой-то причине отсутствует разрешение на запись в группу для нового каталога.

    drwxrwsr-x  2 svn    svn  24K 2008-10-27 10:04 19
    drwxrwsr-x  2 svn    svn  24K 2008-12-18 07:13 20
    drwxr-sr-x  2 jeff   svn 4.0K 2008-12-18 11:18 21

Установка разрешения записи группы в этом каталоге позволяет мне фиксировать, так что я готов к еще 1000 ревизиям. Но почему это происходит, и что я могу изменить, чтобы это больше не повторилось?

Answer 1

Если у вас есть несколько разработчиков, обращающихся к хранилищу по протоколу file://, вы можете захотеть настроить сервер Subversion (используя svnserve или Apache). При таком решении сам сервер отвечает за все права доступа и доступа к файлам репозитория, и вы не столкнетесь с этой проблемой.

Из Книги SVN :

• Не не соблазняйтесь простой идеей, что все ваши пользователи будут иметь доступ к хранилищу напрямую через file:// URL. Даже если репозиторий легко доступен всем через сетевой ресурс, это плохая идея. Он удаляет любые уровни защиты между пользователями и хранилищем: пользователи могут случайно (или намеренно) повредить базу данных хранилища, становится трудно перевести хранилище в автономный режим для проверки или обновления, и это может привести к путанице в проблемах с разрешениями файлов ( см. раздел «Поддержка нескольких методов доступа к репозиторию» ). Обратите внимание, что это также одна из причин, по которой мы предостерегаем от доступа к репозиториям через svn+ssh:// URL-адресов - с точки зрения безопасности, это практически то же самое, что локальные пользователи, осуществляющие доступ через file://, и это может повлечь все те же проблемы, если администратор будьте осторожны.

Answer 2

Лучший способ решить эту проблему - получить доступ к хранилищу через сервер.

Если вы не возражаете против незашифрованной связи (что, похоже, имеет место, поскольку вы используете file://), svnserve очень легко настроить:

svnserve -d -r /svn

См. этот справочник для получения помощи по настройке и настройке аутентификации.

Облом - то, что вам придется настраивать аутентификацию каждого пользователя отдельно.

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

Наконец, если вам нужен самый быстрый способ предотвратить сброс разрешения записи группы при использовании file://, просто попросите всех установить правильный umask (002) при запуске оболочки или используйте svn через скрипт-обертку, это:

#!/bin/bash
# svnwrapper.sh
umask 002
/usr/bin/env svn $*

Убедитесь, что этот umask не является проблемой безопасности в вашей среде.

Answer 3

Наиболее вероятная причина, как сказал Грег. Кто-то обращается к хранилищу по протоколу file: // и имеет чрезмерно ограничительный umask .