部門有3個team,現需要為部門創建一個版本庫,實現項目資源的“集中控制,分散管理”。即能夠滿足每個成員日常的工作需求,又要保護成員不能瀏覽與其無關的資源。
【2.基本思路】
我們在分配權限時都是按照“從嚴不從寬”的原則,所以在分配權限的時候必須小心謹慎---“夠用就行”是不二的選擇。我的模型分為3層結構:
①超級管理員:超級管理員體現了“集中控制”的原則,對所有資源具有最高rw權限。
②組管理員:組管理員體現了“分散管理”的原則,對自己組的項目管理負責
③項目組成員:包括項目組組長和普通項目組員
模型基本思想:
①超級管理員對版本庫下的任何資源有rw權限
②組管理員對組內的任何資源有rw權限
③項目組成員對自己參與的項目有rw權限
④每個組的資源對其他組的成員不可見,除非特別授權
⑤每個組的資源對組內成員均可見,但只有參與成員才有寫權限
⑥如果要跨組或跨項目讀寫,需書面向超級管理員申請開通權限
【3.示例代碼】
首先來看authz這個文件中關于用戶組的定義,我定義了三個基本組:group-ps,group-fix,group-bss。此外還定義了一個group-ehk組用于包含這三個組的所有成員。
為了方便我們前面提到的“分散管理”,我們還需要為每個組定義一個組管理員。這就是group-ps-admin,group-fix-admin,group-bss-admin。同樣的為三個組的管理員創建一個共同組group-team-admin。為了體現我們“集中控制”的原則,我們需要定義一個最高權限的管理員組group-top-admin。
最后是定義一個包含所有人的group-all-user組。
為什么我們需要反復定義這些“組的組”?因為在為大量用戶提供同一個服務時這種做法可以節省很多輸入(例如為項目組,管理員組發送郵件)。



















下面我們來看關鍵的權限控制部分,基本結構為:svn://host_name/department_name/team_name/project_name。
每個項目的check in/out路徑都可以由上面的規則構成,例如部門CBCIO下面的ps組有一個項目newsletter,那么該項目的check in/out路徑為:svn://host_name/CBCIO/ps/newsletter。
示例配置:






















我們的配置遵循“先小后大”的原則,在資源入口處一律收縮到最小,往下根據項目的需要逐漸擴大。而且每個組都只能訪問到該組下面的資源,對于上層的/目錄沒有讀權限。對于公用目錄/common則向所有人開放。
-------------------------------------------------------------
生活就像打牌,不是要抓一手好牌,而是要盡力打好一手爛牌。