上周三下午，止访同事老张在群里发了一张截图，止访SVN客户端弹出一行红字：svn: E170001: Authorization failed。止访他刚改完一个紧急补丁，止访准备提交，止访结果被服务器挡在门外。止访办公室里一阵骚动——这不是止访他一个人的问题，半个组的止访人都连不上仓库了。

运维那边查了半小时，止访最后丢出一句：权限配置被人动过。止访具体谁动的止访、什么时候动的止访，没人说得清。止访SVN的止访权限控制就是这样，平时没人注意，止访一出事就是集体瘫痪。

权限文件到底长什么样

如果你自己搭过SVN服务器，大概率见过conf目录下那两个文件：svnserve.conf和authz。前者管认证方式，后者管谁能读、谁能写。问题往往出在authz上。

一个典型的authz片段长这样：

[groups] dev_team = zhangsan, lisi, wangwu [/] * = r [/trunk/src] @dev_team = rw * = 

最后那行* =意思是“其他人没有任何权限”。看起来干净利落。但很多人不知道，authz文件的解析规则有个坑：后面的规则会覆盖前面的规则，但路径匹配是逐层继承的。你在[/]给了所有人读权限，在[/trunk/src]又收回了，实际效果取决于客户端请求的具体路径和服务器版本的解析顺序。

我见过最离谱的一次，有人把[/]写成[*]，整个仓库直接对匿名用户开放。他还觉得自己写了个“通配符优化”。

为什么“禁止访问”总是来得莫名其妙

SVN的报错信息出了名的含糊。E170001只告诉你认证失败，不告诉你哪个用户、哪条规则、哪个路径触发的。你得像剥洋葱一样一层层试。

有个排查技巧：用svn ls加--username手动指定账号，从根目录往下逐级测。比如：

svn ls svn://192.168.1.10/repo --username zhangsan svn ls svn://192.168.1.10/repo/trunk --username zhangsan svn ls svn://192.168.1.10/repo/trunk/src --username zhangsan 

哪一级开始报错，问题就出在哪一级的规则上。这法子笨，但比对着authz文件瞎猜快得多。

还有一种情况：密码没改，权限也没动，但就是进不去。检查一下svnserve.conf里的password-db和authz-db路径是不是相对路径。SVN服务以守护进程启动时，工作目录可能跟你手动测试时不一样，相对路径直接失效。改成绝对路径，世界立刻安静。

绕不开的“匿名访问”陷阱

svnserve.conf里有一行anon-access，默认值是read。也就是说，哪怕你authz里把权限卡得死死的，匿名用户依然能读仓库内容。很多人搭完服务器只测了提交，没测匿名拉取，结果代码被人扒了个干净还不知道。

把它改成none。除非你明确需要公开只读仓库，否则这行就该是none。我见过三个不同团队的生产环境，两个留着默认的read。问就是“没注意”。

一个真实案例

去年帮朋友公司看他们的SVN。症状是：新入职的员工全部无法访问，老员工正常。运维查了一下午，怀疑是LDAP集成出了问题。

我打开authz，看到这么一段：

[groups] old_staff = user1, user2, user3, user4, user5, user6, user7, user8, user9, user10, user11, user12 [/] @old_staff = rw * = r 

新员工不在old_staff组里，按规则只能读。但他们要提交代码，所以被拒。运维一直在查认证，根本没往授权规则上看。把新员工加进组，或者新建一个all_staff组，问题当场解决。

SVN的权限模型不复杂，但架不住配置散落在两个文件里，加上报错信息不透明，排查起来全靠经验和耐心。下次再看到“禁止访问”，先别急着重启服务。打开authz，从根路径开始，一行一行读。答案通常就在那里。