[转]Subversion的权限控制
2008-08-21 18:25
148 查看
在阅读本文之前,请确定你已经知道了Subversion基本的服务器管理,知道了svnserve或Apache的配置,清楚如何设置用户和密码。关于svnservee的配置可以看我们的《Subversion快速入门教程》和《用Apache和Subversion搭建安全的版本控制环境》,对于一些细节情参考《使用Subversion进行版本控制》。 作为一个配置管理员,需要管理用户的权限,本文主要介绍了使用Subversion的授权文件“authz-db”,同时为了叙述的清晰,我首先澄清一些概念。 1. 认证(Authentication)和授权(Authorization) 这两个术语经常一起出现。其中认证的意思就是鉴别用户的身份,最常见的方式就是使用用户名和密码,授权就是判断用户是否具备某种操作的权限。在Subversion里提供了“authz-db”文件,实现了以路径为基础的授权,也就是判断用户是否有操作对应路径的权限。在Subversion 1.3之后,svnserve和Apache一样都可以使用“authz-db”文件。 2. SVN Serve下的配置文件 因为本文是以svnserve为例的,所以先介绍一下版本库目录的结构: D:\SVNROOT\PROJECT1 ├─conf ├─dav ├─db │ ├─revprops │ ├─revs │ └─transactions ├─hooks └─locks 其中conf下面有三个文件: authz passwd svnserve.conf 其中的“svnserve.conf”是这个版本库的配置文件。当使用svnserve时,这个配置文件决定了使用什么认证和授权文件: password-db = passwd authz-db = authz 上面的配置说明使用“svnserve.conf”同目录的passwd和authz,其中的password-db指定了用户密码文件,authz-db是我们的授权文件,也就是我们本文主要介绍的文件。 注意:使用Apache作为服务器时,根本就不会参考“svnserve.conf”文件的内容,而是会参考Apache的配置。 3. 基于svnserve的版本库文件布局 使用svnserve时,为了管理的方便,应该使用相同的认证和授权文件,所以应该让所有版本库的配置文件svnserve.conf指向同一个password-db和authz-db文件。下面是一个多版本库的目录: D:\SVNROOT ├─project1 │ ├─conf │ ├─dav │ ├─db │ │ ├─revprops │ │ ├─revs │ │ └─transactions │ ├─hooks │ └─locks └─project2 ├─conf ├─dav ├─db │ ├─revprops │ ├─revs │ └─transactions ├─hooks └─locks D:\SVNROOT下有两个目录project1和project2,都已经创建了版本库,所以我们修改每个conf目录下的svnserve.conf,使之指向同一个password-db和authz-db文件。 password-db = ..\..\passwd authz-db = ..\..\authz 这样,D:\SVNROOT\passwd和D:\SVNROOT\authz就控制了所有版本库的svnserve访问。另外在后面的操作中要关闭匿名访问,应该去掉“anon-access = none”前的“#”号,保证只有认证用户可以访问。 注意:还有一点需要注意,那就是svnserve的“realm”的值,在上面的设置下,应该保证所有的版本库使用相同的realm值。这样,对版本库的密码缓存可以在多个版本库之间共享,更多细节见客户端凭证缓存。 4. 测试用户和组说明 版本库禁止任何匿名用户的访问,只对认证用户有效。 root:配置管理管理员,对版本库有完全的管理权限。 p1_admin1:project1的管理员,对project1有完全权限。 p1_d1:project1的开发者,对project1的trunk有完全的权限,但是对其中的/trunk/admin目录没有任何权限。 p1_t1:project1的测试者,对project1的trunk有完全的读权限,但是对其中的/trunk/admin目录没有任何权限。 p2_admin1:project2的管理员,对project2有完全权限。 p2_d1:project2的开发者,对project2的trunk有完全的权限,但是对其中的/trunk/admin目录没有任何权限。 p2_t1:project2的测试者,对project2的trunk有完全的读权限,但是对其中的/trunk/admin目录没有任何权限。 对应的组及组的用户: p1_group_a:p1_admin1 p1_group_d:p1_d1 p1_group_t:p1_t1 p2_group_a:p2_admin1 p2_group_d:p2_d1 p2_group_t:p2_t1 5. 修改D:\SVNROOT\passwd文件 前面已经说过了,用户和密码文件应该是在D:\SVNROOT\passwd,所以我们为每一位用户设置权限,文件内容如下: [users] p1_admin1 = p1_admin1 p1_d1 = p1_d1 p1_t1 = p1_t1 p2_admin1 = p2_admin1 p2_d1 = p2_d1 p2_t1 = p2_t1 为了便于验证,所有密码和用户名一致,如果你使用的是其他认证方式,这一步可能不同,但是用户名应该都是一样的。 6. 配置授权,修改D:\SVNROOT\authz [groups] # 定义组信息 p1_group_a = p1_admin1 p1_group_d = p1_d1 p1_group_t = p1_t1 p2_group_a = p2_admin1 p2_group_d = p2_d1 p2_group_t = p2_t1 [/] # 指定所有的版本库默认只读,root可读写 * = r root = rw [project1:/] # 指定对版本库project1根目录的权限 @p1_group_a = rw @p1_group_d = rw @p1_group_t = r [project1:/trunk/admin] # 指定对版本库project1的/trunk/admin根目录的权限, # p1_group_a读写,p1_group_d和p1_group_t没有任何权限。 @p1_group_a = rw @p1_group_d = @p1_group_t = [project2:/] # 指定对版本库project2根目录的权限 @p2_group_a = rw @p2_group_d = rw @p2_group_t = r [project2:/trunk/admin] # 指定对版本库project1的/trunk/admin根目录的权限 @p2_group_a = rw @p2_group_d = @p2_group_t = 经过以上设置以后,你会发现一些有趣的事情。当使用用户“p1_d1”,检出project1的trunk时,目录是空的,好像admin目录根本不存在一样;当使用p1_d1用户浏览版本库时,能够看到admin目录,但是其中的内容却无法看到。 关于中文目录,也是没有问题的,只是注意要把authz文件转化为UTF-8格式,在我的WINXP的UltraEdit里显示的文件格式为U8-DOS,具体的做法是用UltraEdit打开authz文件,然后选择“文件->转换->ASCII转UTF-8”,然后保存。 再复杂的情况也不过如此,在实际的工作中要首先规划好权限,只赋给用户最小的权限,保证以最小的配置实现最复杂的权限控制。 |
相关文章推荐
- Subversion 实现精细的目录访问权限控制
- Subversion权限控制手册
- Subversion权限控制
- Subversion的权限控制
- subversion 权限控制
- Subversion的权限控制
- Subversion的权限控制
- Subversion权限控制
- [subversion]权限控制里的中文路径怎么写 乱码?
- 最新Subversion(SVN)权限控制配置详解
- Subversion之路--实现精细的目录访问权限控制(v1.0 更新于2006.12.05)(二)
- Ubuntu Server 安装 Subversion实现精细的目录访问权限控制 安装Subversion和Apache sudo apt-get install subversion li
- Subversion的权限控制
- Subversion之路--实现精细的目录访问权限控制 (转)
- Subversion之路实现精细的目录访问权限控制
- Subversion之路--实现精细的目录访问权限控制
- Subversion实现精细的目录访问权限控制
- (转)Subversion权限控制(补充篇)
- [转]Subversion之路--实现精细的目录访问权限控制
- Subversion的权限控制