Subversion的权限控制（转载）

 

 

http://tech.it168.com/d/2007-12-26/200712261015001.shtml

 

在阅读本文之前，请确定你已经知道了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”，然后保存。
    再复杂的情况也不过如此，在实际的工作中要首先规划好权限，只赋给用户最小的权限，保证以最小的配置实现最复杂的权限控制。