-1

我有一个使用 authz 来控制访问的 svn 存储库。结构如下所示：

├── branches
│   └── bob
├── tags
└── trunk
    └── A
        ├── B
        │   └── README.txt
        └── README.txt

假设 authz 授予用户对目录的读取权限A但没有授予B，并且当我尝试分支时它失败A：

[hidden]$ svn copy A ^/branches/bob/A1 -m 'Branching A to branches/bob/A1'
Adding copy of        A
svn: E220001: Commit failed (details follow):
svn: E220001: Access denied

svnserve 的日志说

Authorization Failed recursive read /trunk/A

为什么 svn 有这个限制，有没有办法解决？为什么它B在分支时不忽略，就像做结帐一样？

如果事实证明这是不可能的，那么 svn 与 authz 的最佳工作流程是什么？看起来如果不允许分支，唯一的办法就是每个人都在主干上工作，但这太愚蠢了。

4

2 回答 2

1

SVN 最初的 authz 实现并没有在副本上检查整个子树，但后来添加以解决这个安全漏洞。

所以结论是，SVN 的 authz 从一开始就没有设计好，迟早会有很多 hacky 和肮脏的修复，最终使你的用例不受支持。恕我直言，一个好的实现应该只跟踪从哪里复制分支并检查源的身份验证。

我同意您的用例是完全有效的，并且 Perforce 很好地支持基于路径的授权。不幸的是，你不能在 svn 中做到这一点。您可以切换到 Perforce，或者等待他们改进 authz。

于 2015-03-29T15:50:01.847 回答
0

您对该用户的子节点 B 具有拒绝权限，并且拒绝权限会覆盖读取权限。

当分支 A 时，B 不能被跳过（它在 A 内部，并且就 SVN 知道或关心的而言，它是它的一部分）。这就是为什么你不能这样做。这实际上是一件好事，因为它阻止了您，因为您通常不想要一个缺少源文件夹的分支。

不应该有解决方法，这种行为实际上是有道理的。要使分支操作成功，您需要：

  • 将 B 移出 A
  • 授予用户访问 A 及其下所有内容的权限

我确实理解这可能会令人沮丧，但如果 B 不依赖于 A，或者在 A 上工作的人不关心 B 或需要访问 B - 在这种情况下 B 不应该真的在A里面。

于 2015-03-27T18:31:48.213 回答