VisualSVN 2.5.16 身份验证让我抓狂 - 在 MS Windows 7 中不起作用

VisualSVN 2.5.16 身份验证让我抓狂 - 在 MS Windows 7 中不起作用

服务器上安装有 VisualSVN 2.5.16,开发机器上安装有 Tortoise SVN 1.8.1 作为客户端。

我在 VisualSVN 服务器管理器上为某人设置了权限,以授予他们访问存储库的权限。权限似乎反映在“浏览存储库”界面中,但未反映在 TortoiseSVN 与 VisualSVN 服务器通信时的更新/提交操作中。

示例:我进入了几个月来一直在进行的项目并进行了测试 - 在 VisualSVN 服务器管理器中删除我的权限,这样所有人都无权访问,开发人员组也无权访问。即此时没有人有访问权限。但我仍然可以创建一个测试文件,并将其提交到存储库。然后从存储库中删除该文件并提交。我似乎无法撤销我对存储库的读取或写入权限。

这一变化使得存储库现在显示在 TortoiseSVN 的“存储库浏览器”中(即,我看不到我删除了权限的树枝),但 Windows 7 文件资源管理器上下文菜单中的更新/提交操作仍然可以正常工作。

我想知道是否存在同样的奇怪现象阻止我的同事访问存储库并提交更改,尽管他明确被授予对他正在处理的其他存储库的读/写权限。

我试图解决的根本问题是,为什么同事对存储库的一部分具有只读访问权限,其中授予的访问模式只有两种:对“所有人”授予“无访问权限”,对我们的开发组和他本人授予“读/写”访问权限。他使用该显式登录名对 VisualSVN 进行身份验证,但只获得只读访问权限。根据 VisualSVN 文档,由于他的名字被明确授予读/写访问权限,因此将授予他对存储库文件夹的任何继承或“所有人”访问权限。

具有显式帐户的 VisualSVN 标准版与 Windows 7 上的 TortoiseSVN 之间存在一些奇怪的现象。

答案1

示例:我进入了几个月来一直在进行的项目并进行了测试 - 在 VisualSVN 服务器管理器中删除我的权限,这样所有人都无权访问,开发人员组也无权访问。也就是说,此时没有人有访问权限。但我仍然可以创建一个测试文件,并将其提交到存储库。然后从存储库中删除该文件并提交。我似乎无法撤销我对存储库的读取或写入权限。

我猜您在根级别有一个访问规则,该规则赋予您的帐户读/写访问权限。您在父级别有读/写规则吗?例如,每个人的规则。如果有,则将访问权限切换为无访问权限或完全删除该规则。否则,如果您使用无效的字符大小写输入存储库 URL,每个人的读/写访问规则可能会生效。

在 1.7 版之前,Apache Subversion 以不区分大小写的方式处理存储库名称和路径,以便进行访问控制,在将它们与访问文件的内容进行比较之前,先在内部将它们转换为小写。现在,它会区分大小写地进行这些比较。请参阅 Apache Subversion 1.7。发行说明位于http://subversion.apache.org/docs/release-notes/1.7.html#case-sensitive-authz

为了解决可能的安全问题,您应该从存储库根目录删除每个人的“读/写”访问权限。

笔记:该问题仅影响 Subversion 身份验证/授权类型,不会在 Windows 身份验证/授权(基本和/或集成)中重现。不会在 VisualSVN Server 2.6 及更新版本中重现。

服务器上安装有 VisualSVN 2.5.16,开发机器上安装有 Tortoise SVN 1.8.1 作为客户端。

保持服务器和客户端更新是有意义的,至少在您当前使用的版本中:

相关内容