Subversion & amp; Разрешения SVN + SSH

Question 1

Я хочу настроить несколько репозиториев Subversion, к которым можно получить доступ через SVN + SSH, чтобы каждый репозиторий принадлежал отдельной группе и был доступен только для чтения и записи членам группы. Это то, что я сделал до сих пор:

sudo addgroup myproject
sudo mkdir -p /svn/myproject
sudo svnadmin create /svn/myproject
sudo chown -R :myproject /svn/myproject
sudo chmod -R g+rws /svn/myproject

Однако, что-то с моей настройкой не работает должным образом ...

Несмотря на то, что userone не является членом группы myproject, userone может проверить весь репозиторий. (Это потому, что userone является членом группы sudo?)
usertwo является членом группы myproject, но не может зафиксировать хранилище из-за ошибки: permission denied while accessing /svn/myproject/db/revprops/__something__/__something__

Точка 1) является проблемой, поскольку она может означать, что каждый, имеющий доступ к машине через оболочку, может проверить код. Пункт 2) проблематичен, поскольку пользователь с (очевидно) правами доступа не может зафиксировать хранилище.

Что я делаю не так в этой настройке?

Question 2

Несмотря на то, что userone не является членом группы myproject, userone может извлекать весь репозиторий.

Хранилища, вероятно, доступны для чтения всему миру. Вы можете изменить это, запустив
sudo chmod -R o-rws /svn/myproject
(Это потому, что userone является членом группы sudo?)

Нет, членство в группе sudo просто означает, что вы можете получить права суперпользователя через sudo. SVN не воспользуется этим. (Но в более общем случае, если у пользователя есть права root на компьютере, они могут читать на нем все, вы не можете их остановить.)
usertwo является членом группы myproject, но не может зафиксировать в хранилище

Вероятно, произошло то, что userone зафиксировал некоторые новые файлы в хранилище, и они в конечном итоге принадлежат ему и не доступны для записи группой проекта.
Обычное решение для этого состоит в том, чтобы все каталоги внутри проекта имели установленный бит setgid. Это заставит все файлы, созданные внутри них, принадлежать группе проекта.
sudo chmod -R g+s /svn/myproject
Тогда вам также нужно убедиться, что для каждого umask установлено значение 002, так что файлы будут доступны для групповой записи по умолчанию.

Все это становится довольно сложным и хрупким, поэтому может быть проще обслуживать SVN-репозиторий только через https.

tumbleweed · Answer 1 · 6 June 2012 в 21:01

Несмотря на то, что userone не является членом группы myproject, userone может извлекать весь репозиторий.

Хранилища, вероятно, доступны для чтения всему миру. Вы можете изменить это, запустив
sudo chmod -R o-rws /svn/myproject
(Это потому, что userone является членом группы sudo?)

Нет, членство в группе sudo просто означает, что вы можете получить права суперпользователя через sudo. SVN не воспользуется этим. (Но в более общем случае, если у пользователя есть права root на компьютере, они могут читать на нем все, вы не можете их остановить.)
usertwo является членом группы myproject, но не может зафиксировать в хранилище

Вероятно, произошло то, что userone зафиксировал некоторые новые файлы в хранилище, и они в конечном итоге принадлежат ему и не доступны для записи группой проекта.
Обычное решение для этого состоит в том, чтобы все каталоги внутри проекта имели установленный бит setgid. Это заставит все файлы, созданные внутри них, принадлежать группе проекта.
sudo chmod -R g+s /svn/myproject
Тогда вам также нужно убедиться, что для каждого umask установлено значение 002, так что файлы будут доступны для групповой записи по умолчанию.

Все это становится довольно сложным и хрупким, поэтому может быть проще обслуживать SVN-репозиторий только через https.

Subversion & amp; Разрешения SVN + SSH

1 ответ

Другие вопросы по тегам:

Похожие вопросы: