Subversion создает каталоги ревизий со слишком строгими разрешениями
Этим утром я попытался внести исправления в 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 ревизий. Но почему это происходит и что я могу изменить, чтобы этого больше не повторилось?
Ответы 3
Если у вас более одного разработчика, обращающегося к репозиторию через протокол file://, вы можете изучить возможность настройки сервера Subversion (с использованием svnserve или Apache). В этом решении сам сервер отвечает за весь доступ и разрешения для файлов репозитория, и вы не столкнетесь с этой проблемой.
Из SVN Книга:
- Do not be seduced by the simple idea of having all of your users access a repository directly via
file://URLs. Even if the repository is readily available to everyone via a network share, this is a bad idea. It removes any layers of protection between the users and the repository: users can accidentally (or intentionally) corrupt the repository database, it becomes hard to take the repository offline for inspection or upgrade, and it can lead to a mess of file permission problems (see the section called “Supporting Multiple Repository Access Methods”). Note that this is also one of the reasons we warn against accessing repositories viasvn+ssh://URLs—from a security standpoint, it's effectively the same as local users accessing viafile://, and it can entail all the same problems if the administrator isn't careful.
Наиболее вероятная причина такая, как сказал Грег. Кто-то обращается к репозиторию по протоколу file: // и имеет слишком строгий маска.
Лучший способ решить эту проблему - получить доступ к репозиторию через сервер.
Если вы не возражаете против незашифрованной связи (что, похоже, имеет место, поскольку вы используете file://), svnserve очень легко настроить:
svnserve -d -r /svn
См. эта ссылка для получения помощи в настройке и настройке аутентификации.
Проблема в том, что вам придется настраивать аутентификацию каждого пользователя отдельно.
Чтобы подключиться к аутентификации вашей ОС, вам необходимо настроить сервер Apache SVN, что немного сложнее, см. эти общие инструкции. Вы можете найти конкретные инструкции для вашей ОС, погуглив.
Наконец, если вам нужен самый быстрый способ предотвратить сброс разрешения на запись группы при использовании file://, просто попросите всех установить правильную umask (002) при запуске своей оболочки или используйте svn через сценарий оболочки, который устанавливает его:
#!/bin/bash
# svnwrapper.sh
umask 002
/usr/bin/env svn $*
Убедитесь, что эта маска не является проблемой безопасности в вашей среде.
Нет, у всех одинаковая маска umask, и они используют протокол ssh.