☰

SVN访问配置

tag-icon • tag-icon linux apache-http-server fedora svn
SVN访问配置

我继承了一台用于托管 Subversion 存储库的 Fedora 17 服务器。

我以为它配置了非常有限的访问权限，但今天的一些测试表明，根本没有访问控制，通用 RW，哎呀。

以下是来自系统的一些信息：

uname -a

Linux 3.9.10-100.fc17.x86_64 #1 SMP 2013 年 7 月 14 日星期日 01:31:27 UTC x86_64 x86_64 x86_64 GNU/Linux

httpd-v

服务器版本：Apache/2.2.23 (Unix) 服务器建立时间：2013 年 1 月 29 日 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 公司https://FQDN/svn/proj/dummy-proj/

即使我以非“管理员用户”或“用户列表”中的用户的身份进行身份验证，我也可以完全访问存储库。

我配置错了什么？

更多信息 - 添加于 2017 年 4 月 18 日上午 11:00

看起来‘AuthzSVNAccessFile’行中指定的文件要么没有被读取，要么被完全忽略。

为了测试，我重命名了文件，然后访问存储库时没有任何问题。我还从配置文件中删除了该行，但仍然可以访问存储库。

如何从 AuthzSVN 进行调试？我想查看它正在验证的用户名，并确认正在读取该文件。

谢谢你的帮助

答案1

我从中学到这里SVN上的权限在svn://协议和http(s)://协议之间是不同的。迷人的。

您的 SVN HTTP 权限可能来自您的网络服务器，可能是 Apache、Lighttpd、nginx 等。请参见此处：http://svnbook.red-bean.com/nightly/en/svn.serverconfig.httpd.html

基本上你需要：

  • 找出你用于托管 SVN 的 http(s) 端点的 Web 服务器
  • 确定该 Web 服务器正在使用哪种身份验证机制（如果有）
  • 如果没有身份验证，则通过实施（例如 Windows/LDAP 身份验证、PAM 身份验证、基本身份验证或摘要身份验证）将其锁定，然后为每个用户/组设置特定于 Web 服务器的权限
  • 为了确保最大程度的混淆，请验证您（可能）没有那些完整的 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 或社区贡献者可能会修复它，您可以将补丁下载为稳定更新。运行受支持和不受支持的操作系统之间存在很大差异，特别是如果您的公司依赖此服务器的正确功能。如果您的人们基于此服务器完成重要工作，那么您就是在玩火。

相关内容