在 Subversion 的使用當(dāng)中，存在“認證”、“授權(quán)”兩個概念。認證，即 authentication，是指用戶名與密碼的認證。授權(quán)，即 authorization ，是指某用戶對某個目錄是否具備讀、寫權(quán)限的一種審核。這兩者配合作用，就組成了 Subversion 的整個帳戶管理體系。
在實際的工作當(dāng)中，我們有時候會遇見需要控制項目目錄的訪問權(quán)限的情況，比如說對項目的一些關(guān)鍵模塊進行限制，僅允許少數(shù)授權(quán)人士才可以修改等。由于項目的目錄本身就是作為版本庫的一個部分被 Subversion 所收管，所以我們無法利用操作系統(tǒng)的帳戶權(quán)限體系，來實現(xiàn)授權(quán)控制。因此，這個問題就只有讓svn自己來解決了。
Subversion 提供了面向目錄的帳戶權(quán)限管理功能，通過它，我們就可以很精確地實現(xiàn)項目目錄的訪問控制。不過在 1.2 及其以前的版本，我們只能利用 mod_authz_svn.so 模塊，結(jié)合 Apache 服務(wù)器來實現(xiàn)目錄訪問控制，這對于對 Apache 的配置與使用不是很熟悉的人來說，就不是很方便了。而Subversion終于在 1.3 版本上，在 svnserve.exe 服務(wù)器里面添加了這一功能，方便了很多人。
本文面向那些 Subversion 的管理員，或者任何對 Subversoin 有興趣的人們。本文假定讀者對Subversion有一定的了解，因此不打算對所有涉及到的安裝、使用，做一個細節(jié)性的描述。若對于文章中描述的其他細節(jié)方面有所疑問，請訪問“參考文獻”一節(jié)里面的參考資料。如果你對本文任何地方有什么意見，或者發(fā)現(xiàn)本文有著大大小小的錯誤，請聯(lián)系 zhengxinxing <AT> gmail <DOT> com 。
本文是基于 Subversion 1.3.2、MS Windows 2003 Server Edition 平臺來編寫的，且 Subversion 服務(wù)器是利用 svnserve.exe 來架設(shè)的。不過，本文講述到的絕大多數(shù)內(nèi)容，都是不僅與操作系統(tǒng)平臺無關(guān)，而且與是采用 svnserve(.exe) 還是使用 Apache 來作為 Subversion 服務(wù)器也基本無關(guān)。因此為免羅嗦，本文就以 svnserve(.exe) 為例進行描述，而略過 Apache 服務(wù)器相關(guān)的內(nèi)容，有興趣的讀者可以參考其他文章來在 Apache 服務(wù)器下實現(xiàn)類似的功能。
本文是利用 reST 格式來編寫的，如果你對它感興趣，請訪問 http://docutils.sourceforge.net/rst.html 。如果想要看到更好的html格式，你可以通篇復(fù)制本文到一個文本文件里，然后利用 docutils 的 rst2html.py 腳本編譯它，當(dāng)然，首先你必須安裝 python。
本文的獲得方式：
本章將詳細介紹前一章所涉及的兩個配置文件， svnserve.conf 和 authz.conf，通過對配置逐行的描述，來闡明其中的一些細節(jié)含義。除此之外的其他配置、安裝等內(nèi)容，不是本文重點，讀者若有什么疑問，請參考后面“參考文獻”中列出的一些文檔。
這里首先要注意一點，任何配置文件的有效配置行，都 不允許存在前置空格 ，否則程序可能會出錯，給你一個 Option expected 的提示。也就是說，如果你直接從本文的純文本格式中拷貝了相關(guān)的配置行過去，需要手動將前置的4個空格全部刪除。當(dāng)然了，如果你覺得一下子要刪除好多行的同樣數(shù)目的前置空格是一件苦差使，那么也許 UltraEdit 的“Column Mode”編輯模式，可以給你很大幫助。
arm\conf\svnserve.conf 文件，是 svnserve.exe 這個服務(wù)器進程的配置文件，我們逐行解釋如下。
首先，我們告訴 svnserve.exe，用戶名與密碼放在 passwd.conf 文件下。當(dāng)然，你可以改成任意的有效文件名，比如默認的就是 passwd:
password-db = passwd.conf
接下來這兩行的意思，是說只允許經(jīng)過驗證的用戶，方可訪問代碼庫。 那么哪些是“經(jīng)過驗證的”用戶呢？噢，當(dāng)然，就是前面說那些在 passwd.conf 文件里面持有用戶名密碼的家伙。這兩行的等號后面，目前只允許 read write none 三種值，你如果想實現(xiàn)一些特殊的值，比如說“read-once”之類的，建議你自己動手改源代碼，反正它也是自由軟件:
anon-access = none
auth-access = write
接下來就是最關(guān)鍵的一句呢，它告訴 svnserve.exe，項目目錄訪問權(quán)限的相關(guān)配置是放在 authz.conf 文件里:
authz-db = authz.conf
當(dāng)然，svn 1.3.2 引入本功能的時候，系統(tǒng)默認使用 authz 而不是 authz.conf 作為配置文件。不過可能由于鄙人是處女座的，據(jù)說有著強烈的完美主義情結(jié)，看著 svnserve.conf 有后綴而 passwd 和 authz 沒有就是不爽，硬是要改了。
上述的 passwd.conf 和 authz.conf 兩個文件也可以作為多個代碼庫共享使用，我們只要將它們放在公共目錄下，比如說放在 D:\svn 目錄下，然后在每個代碼庫的 svnserve.conf 文件中，使用如下語句:
password-db = ..\..\passwd.conf
authz-db = ..\..\authz.conf
或者:
password-db = ../../passwd.conf
authz-db = ../../authz.conf
這樣就可以讓多個代碼庫共享同一個用戶密碼、目錄控制配置文件，這在有些情況下是非常方便的。
arm\conf\authz.conf 文件的配置段，可以分為兩類， [group] 是一類，里面放置著所有用戶分組信息。其余以 [arm:/] 開頭的是另外一類，每一段就是對應(yīng)著項目的一個目錄，其目錄相關(guān)權(quán)限，就在此段內(nèi)設(shè)置。
首先，我們將人員分組管理，以便以后由于人員變動而需要重新設(shè)置權(quán)限時候，盡量少改動?xùn)|西。我們一共設(shè)置了5個用戶分組，分組名稱統(tǒng)一采用 g_ 前綴，以方便識別。當(dāng)然了，分組成員之間采用逗號隔開:
[groups]
# 任何想要查看所有文檔的非本部門人士
g_vip = morson
# 經(jīng)理
g_manager = michael
# 北京辦人員
g_beijing = scofield
# 上海辦人員
g_shanghai = lincon
# 總部一般員工
g_headquarters = rory, linda
# 小秘，撰寫文檔
g_docs = linda
注意到?jīng)]有， linda 這個帳號同時存在“總部”和“文檔員”兩個分組里面，這可不是我老眼昏花寫錯了，是因為 Subversion 允許我這樣設(shè)置。它意味著，這個家伙所擁有的權(quán)限，將會比他的同事 rory 要多一些，這樣的確很方便。具體多了哪些呢？請往下看！
接著，我們對項目根目錄做了限制，該目錄只允許arm事業(yè)部的經(jīng)理才能修改，其他人都只能眼巴巴的看著:
[arm:/]
@g_manager = rw
* = r
- [arm:/] 表示這個目錄結(jié)構(gòu)的相對根節(jié)點，或者說是 arm 項目的根目錄。其中的 arm 字樣，其實就是代碼庫的名稱，即前面用 svnadmin create 命令創(chuàng)建出來的那個 arm。
- 這里的 @ 表示接下來的是一個組名，不是用戶名。因為目前 g_manager 組里面只有一個 michael，你當(dāng)然也可以將 @g_manager = rw 這一行替換成 michael = rw ，而表達的意義完全一樣。
- * 表示“除了上面提到的那些人之外的其余所有人”，也就是“除了部門經(jīng)理外的其他所有人”，當(dāng)然也包括總經(jīng)理那個怪老頭
- * = r 則表示“那些人只能讀，不能寫”
然后，我們要給總部人員開放日志目錄的讀寫權(quán)限:
[arm:/diary/headquarters]
@g_manager = rw
@g_headquarters = rw
@g_vip = r
* =
這個子目錄的設(shè)置有些特色，因為從需求分析中我們知道，這個子目錄的權(quán)限范圍要比其父目錄小，它不允許除指定了的之外其他任何人訪問。在這段設(shè)置中，我們需要注意以下幾點：
- 我敢打賭，設(shè)計svn的家伙們，大部分都是在類 unix 平臺下工作，所以他們總喜歡使用 / 來標識子目錄，而完全忽視在 MS Windows 下是用 \ 來做同樣的事情。所以這兒，為了表示 diary\headquarters 這個目錄，我們必須使用 [arm:/diary/headquarters] 這樣的格式。當(dāng)然如果你一定要用 \ ，那么唯一的結(jié)果就是，Subversion 會將你的這部分設(shè)置置之不理，全當(dāng)沒看到。
- 這里最后一行的 * = 表示，除了經(jīng)理、總部人員、特別人士之外，任何人都被禁止訪問本目錄。這一行是否可以省略呢？不行，因為 權(quán)限具備繼承性 ，子目錄會自動擁有父目錄的權(quán)限。若沒有這一行，則所有帳號都可以讀取 /diary/headquarters 目錄下的文件。因為雖然我們并沒有設(shè)置這個目錄的父目錄權(quán)限，可是默認的規(guī)則使得 /diary 目錄的權(quán)限與根目錄完全一樣，從而讓其余帳號獲得對 /diary/headquarters 目錄的 r 權(quán)限。所以簡單來說， * = 這一句的目的，就是割斷權(quán)限繼承性，使得管理員可以定制某個目錄及其子目錄的權(quán)限，從而完全避開其父目錄權(quán)限設(shè)置的影響。
- 之所以這兒需要將 @g_vip = r 一句加上，就是因為存在上述這個解釋。如果說你沒有明確地給總經(jīng)理授予讀的權(quán)力，則他會和其他人一樣，被 * = 給排除在外。
- 如果眾位看官中間，有誰玩過防火墻配置的話，可能會感覺上述的配置很熟悉。不過這里有一點與防火墻配置不一樣，那就是各個配置行之間，沒有 先后順序 一說。也就是說，如果我將本段配置的 * = 這一行挪到最前面，完全不影響整個配置的最終效果。
接下來我們看看這一段:
[arm:/ref]
@g_manager = rw
@g_docs = rw
* = r
這里的主要看點，就是 g_docs 組里面包含了一個 linda 帳號，她也同時在 g_headquarters 組里面出現(xiàn)，這就意味著， linda 將具備對 /ref 和 diary\headquarters 兩個目錄的讀寫權(quán)限。
在前面的描述中，我們都采用 [repos:/some/dir] 這樣的格式來表示項目的某個目錄，比如上一小節(jié)中的 [arm:/diary/headquarters] 。而實際上，Subversion 允許你采用 `[/some/dir] 這樣的格式，即不指定代碼庫的方式來表示目錄，此時的目錄就匹配所有項目。
對于使用 svnserve 的用戶來說，只有當(dāng) svnserve 運行的時候使用了 -r 參數(shù)，并且讓多個代碼庫共享同一個目錄權(quán)限文件（即 authz.conf 或 authz）時，不指明代碼庫名稱才有可能惹麻煩。一般情況下，我們對每個代碼庫都會獨立使用配置文件，畢竟每個項目的目錄結(jié)構(gòu)，都有很大不同，混在一起意義不大。因此一般來說，為簡潔起見，都可以不指明代碼庫名稱。本文全都指明了代碼庫名稱，主要是為了將來擴展成同一個配置文件，以方便配合 Apache 服務(wù)器。
對于使用 Apache 的用戶來說，它們二者可有著很大的不同，因為此時往往習(xí)慣于使用一個公共的目錄權(quán)限配置文件。如果你使用了 SVNParentPath 指令，則指定版本庫的名字是很重要的，因為假若你使用后者，那么 [/some/dir] 部分就會與所有代碼庫項目的 [/some/dir] 目錄匹配。如果你使用 SVNPath 指令，則這兩種表示方式就沒有什么區(qū)別了，畢竟只有一個版本庫。
- 父目錄的 r 權(quán)限，對子目錄 w 權(quán)限的影響
把這個問題專門提出來，是因為在1.3.1及其以前的版本里面，有個bug，即某個帳號為了對某個子目錄具備寫權(quán)限，則必須對其父目錄具備讀權(quán)限。因此現(xiàn)在使用了1.3.2及其更高的版本，就方便了那些想在一個代碼庫存放多個相互獨立的項目的管理員，來分配權(quán)限了。比如說央舜公司建立一個大的代碼庫用于存放所有員工日志，叫做 diary，而arm事業(yè)部只是其中一個部門，則可以這樣做:
[diary:/]
@g_chief_manager = rw
[diary:/arm]
@g_arm_manager = rw
@g_arm = r
這樣，對于所有arm事業(yè)部的人員來說，就可以將 svn://192.168.0.1/diary/arm 這個URL當(dāng)作根目錄來進行日常操作，而完全不管它其實只是一個子目錄，并且當(dāng)有少數(shù)好奇心比較強的人想試著 checkout 一下 svn://192.168.0.1/diary 的時候，馬上就會得到一個警告“Access denied”，哇，太酷了。
- 默認權(quán)限
如果說我對某個目錄不設(shè)置任何權(quán)限，會怎樣？馬上動手做個試驗，將:
[diary:/]
@g_chief_manager = rw
改成:
[diary:/]
# @g_chief_manager = rw
這樣就相當(dāng)于什么都沒有設(shè)置。在我的 svn 1.3.2 版本上，此時是禁止任何訪問。也就是說，如果你想要讓某人訪問某目錄，你一定要顯式指明這一點。這個策略，看起來與防火墻的策略是一致的。
- 只讀權(quán)限帶來的一個小副作用
若設(shè)置了:
[arm:/diary]
* = r
則 Subversion 會認為，任何人都不允許改動 diary 目錄，包括刪除、 改名 ，和 新增 。
也就是說，如果你在項目初期創(chuàng)建目錄時候，一不小心寫錯目錄名稱，比如因拼寫錯誤寫成 dairy，以后除非你改動 authz.conf 里面的這行設(shè)置，否則無法利用 svn mv 命令將錯誤的目錄更正。
- anon-access 屬性對目錄權(quán)限的影響
你想將你的代碼庫開放給所有人訪問，于是你就開放了匿名訪問權(quán)限，在 svnserve.conf 文件中添加一行： anon-access=read 。可是對于部分目錄，你又不希望別人看到，于是針對那些特別目錄，你在 authz.conf 里面進行配置，添加了授權(quán)訪問的人，并添加了 * = 標記。你認為一切OK了，可是你缺發(fā)現(xiàn)，那個特別目錄卻無法訪問了，總是提示 Not authorized to open root of edit operation 或者 未授權(quán)打開根進行編輯操作 。你再三檢查你配置的用戶名與密碼，確認一切正確，還是無法解決問題。
原來，Subversion 有個小 bug ，當(dāng) anon-access=read 并且某個目錄有被設(shè)置上 * = 標記，則會出現(xiàn)上述問題。這個 bug 在當(dāng)前最新版本上（v1.4）還存在，也許在下一版本內(nèi)可以被改正吧。
解決的辦法是，在 svnserve.conf 中，將 anon-access 設(shè)置成 none 。