Конфигурация доступа SVN

Question

Я унаследовал сервер Fedora 17, который используется для размещения репозиториев Subversion.

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

Вот некоторая информация из системы:

uname -a

Linux 3.9.10-100.fc17.x86_64 # 1 SMP Sun 14 июля 01:31:27 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

httpd -v

Версия сервера: Apache/2.2.23 (Unix) Сервер построен: 29 января 2013 12:37:17

Вот фрагмент части файлов конфигурации HTTPD

<Location /svn/proj>
    DAV                             svn
    SVNParentPath                   /data/subversion/repos/proj
    SVNAutoversioning               On
    SSLRequireSSL
    SVNIndexXSLT                    "/repostyle-proj/view/repos.xsl"
    AuthType                        Basic
    AuthName                        "Project Authorization"
    PerlAuthenHandler               Apache::AuthPOP3
    PerlSetVar                      MailHost 127.0.0.1
    AuthBasicAuthoritative          On
    AuthzSVNAccessFile              /data/subversion/conf/perms_proj
    Require valid-user
    SVNAdvertiseV2Protocol Off

</Location>

Вот фрагмент файла разрешений SVN

[groups]
admins=admin-user
dummy-proj=<list of users>

[/]
@admins=rw

[dummy-proj:/]
@dummy-proj=rw

При беге

svn co https://FQDN/svn/proj/dummy-proj/

Я получаю полный доступ к хранилищу, даже если я аутентифицируюсь как пользователь, который не является «admin-user» или пользователем в «списке пользователей».

Что я неправильно настроил?

Больше информации - добавлено 18.04.17 в 11:00

Похоже, что файлы, указанные в строках AuthzSVNAccessFile, либо не читаются, либо полностью игнорируются.

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

Как я могу получить некоторую отладку от AuthzSVN? Я хочу увидеть имя пользователя, с которым оно проверяет, и подтвердить, что файл читается.

Спасибо за любую помощь

Answer 1

Отсюда я узнал, что разрешения для SVN различаются между протоколом svn:// протоколом http(s):// . Прекрасный

Ваши разрешения SVN HTTP, вероятно, поступают с вашего веб-сервера, которым могут быть Apache, Lighttpd, nginx и т.д. См. Здесь: http://svnbook.red-bean.com/nightly/en/svn.serverconfig.httpd.html.

В основном вам нужно:

• Узнайте, какой веб-сервер вы используете для размещения конечной точки http(s) для SVN
• Определите, какой механизм аутентификации используется этим веб-сервером, если таковой имеется
• Если нет аутентификации, заблокируйте ее, реализовав, например, аутентификацию Windows/LDAP, аутентификацию PAM, базовую аутентификацию или дайджест-аутентификацию, затем установите разрешение для веб-сервера для каждого пользователя / группы.
• Просто, чтобы обеспечить максимальную путаницу, убедитесь, что у вас (возможно) нет этих полных прав доступа R / W, если вы используете svn co svn:// (используя собственный протокол SVN, а не HTTP).

---

Кстати, это не имеет отношения к вашему вопросу, но Fedora 17 не поддерживалась для обновлений безопасности или исправления ошибок в течение примерно 4 лет, поэтому вам действительно нужно перейти на поддерживаемую ОС. RHEL/CentOS 7.x основан на Fedora 19 (с большим количеством новых исправлений и бэкпортов для улучшения поддержки и стабильности оборудования), поэтому из-за сходства между Fedora 17 и CentOS/RHEL 7.x он будет относительно низким чтобы сохранить файлы конфигурации и данные с сервера и переустановить ОС под именем CentOS/RHEL 7.x. И тогда вы снова будете получать постоянный поток обновлений безопасности в течение еще нескольких лет (примерно до 2023 года).

Если вы сталкиваетесь с проблемами, которые напоминают ошибки или нарушенную функциональность в Fedora 17, почти никто не будет мотивирован, чтобы помочь вам в любом качестве, так что это еще одна мотивирующая причина для обновления. Если вы обнаружите что-то неработающее в CentOS 7.x и сможете написать хороший отчет об ошибке, это может на самом деле исправить Red Hat или участник сообщества, и вы можете загрузить исправление в качестве стабильного обновления. Существует большая разница между поддержкой поддерживаемой и неподдерживаемой ОС, особенно если ваша компания полагается на правильную функциональность этого сервера. Вы играете с огнем, если у вас есть люди, выполняющие важную работу на основе этого сервера.