SVN用户权限管理讲解
/***********************************************************/
//SVNSubversion 用户权限管理//资料来源：网络、总结//2010年7月20日
/***********************************************************/ 基本的操作：以我创建的Svn工程为例子来讲解SVN权
/***********************************************************/ //SVNSubversion 用户权限管理
//资料来源：网络、总结
//2010年7月20日
/***********************************************************/
基本的操作：
以我创建的Svn工程为例子来讲解SVN权限管理的配置
仓库创建路径：D:\SVNLibrary
>>>取消匿名登陆：
打开文件D:\SVNLibrary\conf\svnserve.conf
找到：###anon-access = read
将前面的注释去掉，并将read 改为：none
即使：anoe-access=none 表示匿名登陆下的用户权限为空。即：系统不支持匿名登陆
说明：
auth-access = write #通过验证的用户可以读和写
auno-access = read #匿名登陆下可以只读文件，即：文件修改后无法提交到服务器
password-db =password #用户保存文件的名称
authz-db =authz #权限管理文件这个是非常重要的，如果我们要对整个工程的文件进行权限分配的时候，就必须将这个行文件前面注释掉，否咋即使我们在权限配置文件里面进行再多的配置都是无效的。这点我已经犯错了。
然后我们在authz 文件下面进行权限的分配
在权限分配的时候要注意的问题：
>>>权限分配时，应遵守从根目录到子目录、从设置最广泛权限到最精细权限、从只读权限到读写权限设置原则，即从根目录开始设置最广泛的访问权限，然后逐步设置下属子目录的访问权限。提示：目录的访问权限既可以分配给组，也可以分配指定用户。
>>>对某个用户，如果只赋给他某个目录的权限，但对上级目录没有赋给，则他不能有上级目录的任何权限
例如某个用户有：/repository/project1的r权，而没有/repository的r权
>>>对于所有的目录，都优先处理设置在这个目录上的权限设置。
例如sai用户：
[/repository]
sai = rw
对于repository目录，他有rw的权限。
[/repository/project1]
sai = r
对于repository下的project1目录，他只有r权限。
则，这个saiy用户只有project1的r权。而repository下其他目录有rw权。
>>>权限分配，只可以分配到某个目录，而不能到某个文件
>>>如果某个目录上没有对某个用户设置权限，则一直向上级目录查找，看是否有权限
例如sai用户
[/repository]
sai=rw
[/repository/project1]
saiya=rw
则sai用户一样拥有/repository/project1的读写权限
>>>分配权限时，= 的左边为用户，不能想当然的以，号分开加入多个用户
>>>如果想设置某用户都没有rw的权限，只要= 号的右边这空即可
User1 =
>>>如果某一个文件夹，对于人任何用户都没有权限
* =
其中*代表所有的人
SVN深入的部分
本章将详细介绍前一章所涉及的两个配置文件，svnserve.conf 和authz.conf，通过对配置逐行的描述，来阐明其中的一些细节含义。
这里首先要注意一点，任何配置文件的有效配置行，都不允许存在前置空格，否则程序会无法识别。也就是说，如果你直接从本文的纯文本格式中拷贝了相关的配置行过去，需要手动将前置的4个空格全部删除。当然了，如果你觉得一下子要删除好多行的同样数目的前置空格是一件苦差使，那么也许UltraEdit 的“Column Mode”编辑模式，可以给你很大帮助呢。
1 svnserve.conf
arm\conf\svnserve.conf 文件，是svnserve.exe 这个服务器进程的配置文件，我们逐行解释如下。
首先，我们告诉svnserve.exe，用户名与密码放在passwd.conf 文件下。当然，你可以改成任意的有效文件名，比如默认的就是passwd:
password-db = passwd.conf
接下来这两行的意思，是说只允许经过验证的用户，方可访问代码库。那么哪些是“经过验证的”用户呢？噢，当然，就是前面说那些在passwd.conf 文件里面持有用户名密码的家伙。这两行的等号后面，目前只允许read write none 三种值，你如果想实现一些特殊的值，比如说“read-once”之类的，建议你自己动手改源代码，反正它也是自由软件：
anon-access = none
auth-access = write
接下来就是最关键的一句呢，它告诉svnserve.exe，项目目录访问权限的相关配置是放在authz.conf 文件里：
authz-db = authz.conf
当然，svn 1.3.2 引入本功能的时候，系统默认使用authz 而不是authz.conf 作为配置文件。不过由于鄙人是处女座的，有着强烈的完美主义情结，看着svnserve.conf 有后缀而passwd 和authz 没有就是不爽，硬是要改了。
2 authz.conf 之用户分组
arm\conf\authz.conf 文件的配置段，可以分为两类，``[group]`` 是一类，里面放置着所有用户分组信息。其余以[arm:/] 开头的是另外一类，每一段就是对应着项目的一个目录，其目录相关权限，就在此段内设置。
首先，我们将人员分组管理，以便以后由于人员变动而需要重新设置权限时候，尽量少改动东西。我们一共设置了5个用户分组，分组名称统一采用g_ 前缀，以方便识别。当然了，分组成员之间采用逗号隔开：
[groups]
# 任何想要查看所有文档的非本部门人士
g_vip = morson
# 经理
g_manager = michael
# 北京办人员
g_beijing = scofield
# 上海办人员
g_shanghai = lincon
# 总部一般员工
g_headquarters = rory, linda
# 小秘，撰写文档
g_docs = linda
注意到没有，linda 这个帐号同时存在“总部”和“文档员”两个分组里面，这可不是我老眼昏花写错了，是因为svnserve.exe 允许我这样设置。它意味着，这个家伙所拥有的权限，将会比他的同事rory 要多一些，这样的确很方便。具体多了哪些呢？请往下看！3 authz.conf 之项目根目录接着，我们对项目根目录做了限制，该目录只允许arm事业部的经理才能修改，其他人都只能眼巴巴的看着：
#设置对根（即SVNLibrary）目录下，所有版本库的访问权限
[/]
* = r #所有登录用户默认权限为只读
[arm:/] #设置对arm版本库中，所有项目的访问权限
@g_manager = rw
* = r
[arm:/] 表示这个目录结构的相对根节点，或者说是arm 项目的根目录
这里的@ 表示接下来的是一个组名，不是用户名。你当然也可以将
@g_manager=rw 这一行替换成michael=rw ，而表达的意义完全一样。
* 表示“除了上面提到的那些人之外的其余所有人”，也就是“除了部门经理外的其他所有人”，当然也包括总经理那个怪老头
* = r 则表示“那些人只能读，不能写”
4 authz.conf 之项目子目录
然后，我们要给总部人员开放日志目录的读写权限：
[arm:/diary/headquarters]
@g_manager = rw
@g_headquarters = rw
@g_vip = r
* =
我敢打赌，设计svn的家伙们，大部分都是在unix/linux 平台下工作，所以他们总喜欢使用/ 来标识子目录，而完全忽视在MS Windows 下是用\ 来做同样的事情。所以这儿，为了表示arm\diary\headquarters 这个目录，我们必须使用
[arm:/diary/headquarters] 这样的格式。
这里最后一行的*= 表示，除了经理、总部人员、特别人士之外，任何人都被禁止访问本目录。这一行是否可以省略呢？
之所以这儿需要将@g_vip=r 一句加上，就是因为存在上述这个解释。如果说你没有明确地给总经理授予读的权力，则他会和其他人一样，被* 给排除在外。
如果众位看官中间，有谁玩过防火墙配置的话，可能会感觉上述的配置很熟悉。不过这里有一点与防火墙配置不一样，那就是各个配置行之间，没有先后顺序一说。也就是说，如果我将本段配置的*= 这一行挪到最前面，完全不影响整个配置的最终效果。
请注意这儿，我们并没有给arm\diary 目录设置权限，就直接跳到其子目录下进行设置了。我当然是故意这样的，因为我想在这儿引入“继承”的概念。
权限具备继承性任何子目录，均可继承其父目录的所有权限，除非它自己被明确设置了其他的权限。也就是说，在arm 目录设置权限后，arm\diary 目录没有进行设置，就意味着它的权限与arm 目录一样，都是只有经理才有权读写，其他人只能干瞪眼。
【* = 是否可以省略】【用例子引入覆盖】【单用户权限的继承问题】【父目录权限集成与全面覆盖问题】
现在来看看
好了，我们现在掌握了“继承”的威力，它让我们节省了不少敲键盘的时间。可是现在又有一个问题了，
属性具备覆盖性质子目录若设置了属性，则完全覆盖父目录。
5 authz.conf 的其他注意点
父目录的r 权限，对子目录w 权限的影响
把这个问题专门提出来，是因为在1.3.1及其以前的版本里面，有个bug，即为了子目录的写权限，项目首目录必须具备读权限。因此现在使用了1.3.2版本，就方便了那些想在一个代码库存放多个相互独立的项目的管理员，来分配权限了。比如说央舜公司建立一个大的代码库用于存放所有员工日志，叫做diary，而arm事业部只是其中一个部门，则可以这样做：
[diary:/]
@g_chief_manager = rw
[diary:/arm]
@g_arm_manager = rw
@g_arm = r
这样，对于所有arm事业部的人员来说，就可以将svn://192.168.0.1/diary/arm 这个URL当作根目录来进行日常操作，而完全不管它其实只是一个子目录，并且当有少数好奇心比较强的人想试着checkout 一下svn://192.168.0.1/diary 的时候，马上就会得到一个警告“Access deni”，哇，太酷了。
默认权限
如果说我对某个目录不设置任何权限，会怎样？马上动手做个试验，将：
[diary:/]
@g_chief_manager = rw
改成：
[diary:/]
# @g_chief_manager = rw
这样就相当于什么都没有设置。在我的svn 1.3.2 版本上，此时是禁止任何访问。也就是说，如果你想要让某人访问某目录，你一定要显式指明这一点。这个策略，看起来与防火墙的策略是一致的。
只读权限带来的一个小副作用
若设置了：
[arm:/diary]
* = r
则svnserve认为，任何人，都不允许改动diary目录，包括删除和改名，和新增。
也就是说，如果你在项目初期创建目录时候，一不小心写错目录名称，比如因拼写错误写成dairy，以后除非你改动authz.conf 里面的这行设置，否则无法利用svn mv 命令将错误的目录更正。
改进
1 对中文目录的支持
上午上班的时候，Morson 来到Michael 的桌子前面，说道：“你是否可以将我们的北京办、上海办目录，改成用中文的，看着那些拼音我觉得很难受？” Michael 心想，还好这两天刚了解了一些与unicode 编码相关的知识，于是微笑地回答：“当然可以，你明天下午就可以看到中文目录名称了。”
使用svn mv 指令，将原来的一些目录改名并commit 入代码库，改名后的目录结构如下：
arm
├─工作日志
│├─总部人员
│├─北京办
│└─上海办
├─公司公共文件参考目录
└─临时文件存放处
修改代码库的authz.conf 文件，将相应目录逐一改名
使用UltraEdit 将authz.conf 文件转换成不带BOM 的UTF-8 格式
将配置文件转换成UTF-8 格式之后，Subversion 就能够正确识别中文字符了。但是这里需要注意一点，即必须保证UTF-8 文件不包含BOM 。BOM 是Byte Order Mark 的缩写，指UNICODE 文件头部用于指明高低字节排列顺序的几个字符，通常是FFFE ，而将之用UTF-8 编码之后，就是EFBBBF 。由于UTF-8 文件本身不存在字节序问题，所以对UTF-16 等编码方式有重大意义的BOM，对于U
XXXX集团信息系统用户帐号及权限管理制度 管理要求 1．使用信息系统的各业务部门各岗位人员，除公司有特殊规定外，皆按本制度执行。 2．职责：网络管理部门负责用户的创建和权限分配，各业务部门根据各自岗位需求向信息系统管理部门提出用户创建需求和权限分配需求。 3．信息系统用户的管理：包括系统用户帐号的命名建立，用户帐号及相应权限的增加、修改，用户帐号及相应权限的终止，用户密码的修改，用户帐号及相应权限的锁定和解锁；用户帐号及相应权限的安全管理等。 4．信息系统管理员（以下简称系统管理员）在系统中不得任意增加、修改、删除用户帐号及相应权限，必须根据《XXXX集团信息系统申请表》和相关领导签字审批才能进行相应操作，并将相关文档留档备存。 5．用户帐号及相应权限的持有人，必须保证用户帐号及相应权限和用户密码的保密和安全，不得对外泄漏，防止非此用户帐号的所有者登陆系统。 6．公司用户管理员要定期检查系统内用户使用情况，防止非法授权用户恶意登陆系统，保证系统的安全。 7．帐号持有人要对其在系统内的行为负责，各部门领导要对本单位或本部门用户的行为负责。 8．用户帐号的命名由系统管理员执行，用户帐号命名应遵循易用性、最小重叠机率为用户帐号的命名规则，不得随意命名。 9.对用户申请表等相关文档各申请部门的用户管理员必须存档，不得遗失。 页脚内容1
增加、修改用户帐号及相应权限的管理 10.信息系统中增加、修改用户帐号及相应流程规范： 10.1 新增员工：新员需要使用公司内部通讯系统，首先填写《XXXX集团信息系统申请表》ERP系统用户申请填写《XXXX集团公司ERP权限申请表》,由主管部门负责人核定审批、人事部复核审批，交由网络部留档备存、执行相应操作。 10.2 系统组织结构调整：部门新建、合并、分离、撤消，组织结构需求变更的。需由部门主管领导提出书面说明文件，报人事部审核，各分公司总经理复核，交由网络部留档备存、执行相应操作。 11.用户帐号及相应权限的增加、修改，须由申请人填写《XXXX集团信息系统申请表》、《XXXX集团公司ERP权限申请表》，所在部门负责人审批，网络安全部门负责人审批后交由系统管理员留档备存、执行相应操作。 用户帐号及相应权限终止的管理 12.用户帐号及相应权限的终止应符合：①用户帐号持有人工作调动，②用户帐号持有人辞职。 13.用户帐户持有人因工作调动需要终止帐户的，自相应调动通知公布后。由所属公司人事部门以书面方式通知网络管理部门，网络管理部门负责人审批后交由系统管理员留档备存、执行删除或冻结操作。 14.对于辞职人员用户帐号及相应权限终止，离职人员办理离职申请表，其它部门手续办理完结签字后，转由网络部及时清理该员工各系统帐号。 用户帐号的安全管理 15.用户帐号持有人忘记密码必须填写《XXXX集团信息系统申请表》，所在部门负责人审批，网络管理部门负责人审批后经系统管理员执行相应的操作。 页脚内容2
物流信息系统用户和权限管理制度 第一章总则 第一条为加强物流信息系统用户账号和权限的规范化管理,确保物流信息系统安全、有序、稳定运行，防范应用风险，杜绝公司商业数据外泄，特制定本制度。 第二条物流信息系统用户、角色、权限的划分和制定，以人力资源部对部门职能定位和各业务部门内部分工为依据。 第三条物流信息系统须指定系统管理员负责用户和权限管理的具体操作。 第四条物流信息系统用户和权限管理的基本原则是： （一）账号申请或权限修改，由使用人报本部门分管副总和总经理审核。 （二）用户、权限和口令设置、U盾由系统管理员全面负责。 （三）用户、权限和口令管理、U盾必须作为物流信息系统登陆的强制性技术标准或要求。 （四）用户采用实名制管理模式。 （五）用户必须使用自己的U盾和密码登陆系统，严禁挪用、转借他人。 第二章管理职责 第五条超级系统管理员职责 负责本级用户管理以及对下一级系统管理员管理。包括创建各类申请用户、用户有效性管理、为用户分配经授权批准使用的业务系统、为业务管理员提供用户授权管理的操作培训和技术指导。 第八条业务管理员职责 负责本级本业务系统角色制定、本级用户授权及下一级本业务系统业务管理员管理。负责将上级创建的角色或自身创建的角色授予相应的本级用户和下一级业务管理员，为本业务系统用户提供操作培训和技术指导，使其有
权限实施相应业务信息管理活动。 第九条用户职责 用户须严格管理自己用户名和口令以及U盾，遵守保密性原则，除获得授权或另有规定外，不能将收集的数据信息向任何第三方泄露或公开。系统内所有用户信息均必须采用真实信息，即实名制登记。 第三章用户管理 第十条用户申请和创建 （一）申请人在《用户账号申请和变更表》上填写基本情况，提交所在部门分管副总； （二）所在部门分管副总确认申请业务的用户身份权限，并在《用户账号申请和变更表》上签字确认，提交总经理审核。 （三）总经理审核并在《用户账号申请和变更表》上签字确认。 （四）申请人持签字确认的《用户账号申请和变更表》到行政后勤部领取U盾（修改权限不需领取U盾）。 （五）申请人持签字确认的《用户账号申请和变更表》和U盾到信息中心,创建用户或者变更权限。 （六）系统管理员和业务管理员将创建的用户名、口令告知申请人本人，并要求申请人及时变更口令； （七）系统管理员和业务管理员将《用户账号申请和变更表》存档管理。 第十一条用户变更和停用 （一）用户因工作岗位变动，调动、离职等原因导致使用权限发生变化或需要注销其账号时，应填写《用户账号申请和变更表》，按照用户账号停用的相关流程办理，由系统管理员和业务管理员对其权限进行修改或注销。 （二）行政后勤部主管确认此业务用户功能权限改变原因或离职，并在《用户账号申请和变更表》上签字确认； （三）用户归属部门主管确认此业务用户功能权限改变原因或离职，并
作为一个配置管理员，需要管理用户的权限，本文主要介绍了使用Subversion的授权文件“authz-db”，同时为了叙述的清晰，我首先澄清一些概念。 认证（Authentication）和授权（Authorization） 这两个术语经常一起出现。其中认证的意思就是鉴别用户的身份，最常见的方式就是使用用户名和密码，授权就是判断用户是否具备某种操作的权限，在Subversion里提供了“authz-db”文件，实现了以路径为基础的授权，也就是判断用户是否有操作对应路径的权限。svnserve下的配置文件 因为本文是以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是我们的授权文件，也就是我们本文主要介绍的文件。 基于svnserve的版本库文件布局 使用svnserve时，为了管理的方便，应该使用相同的认证和授权文件，所以应该让所有版本库的配置文件svnserve.conf指向同一个password-db和authz-db文件。下面是一个多版本库的目录： D:\SVNROOT ├─project1 │ ├─conf │ ├─dav │ ├─db
XXXXXX有限公司 管理信息系统权限管理制度 XXX-XX-XX 第一章总则 第一条目的 为规范公司管理信息系统的权限管理工作，明确不同权限系统用户的管理职责，结合公司实际情况，特制定本管理制度。 第二条定义 （一）管理信息系统：包含已经上线的财务会计、管理会计、供应链、生产制造、CRM（客户关系管理）、决策管理和后续上线的所有管理信息系统模块。 （二）权限：在管理信息系统中用户所能够执行的操作及访问数据的范围和程度。 （三）操作员：上述软件系统使用人员。 第三条适用范围 本制度适用于XXXXXX有限公司（以下简称XXXX、公司）、XXXXXXX有限公司、XXXXXX有限公司、XXXXXXXX有限公司。 XXXX股份有限公司控、参股的其他公司，应结合本公司实际情况，参照本制度制定相应管理制度，报XXXX质量信息部备案。 第二章职责划分 第四条管理信息系统管理部门 公司的管理信息系统由质量信息部负责管理和维护，同时也是管理信息系统用户权限的归口管理部门，主要负责各系统内用户权限的审批、开通、监控、删除及通知等管理工作。 第五条管理信息系统操作部门 除管理信息系统管理部门外，其他使用管理信息系统的部门，均为管理信息系统的操作部门，使用人员为各岗位操作员。
具体岗位职责如下： （一）负责岗位信息系统权限的申请及使用，并对权限申请后形成的业务结果负责。 （二）负责所使用模块的数据安全。 第六条管理信息系统系统管理员 管理信息系统的系统管理员由质量信息部指派，并报公司管理层领导备案。 系统管理员负责用户帐号管理、用户角色权限分配和维护、各模块运行的安全监管及数据备份，并定期进行管理信息系统安全审计。 第三章用户权限管理 第七条用户权限申请 各部门依据实际工作情况，当需要新增/变更/注销管理信息系统的用户权限时，可由操作员本人或所在部门领导指派的专人，填写《ERP权限新增/变更/注销申请表》（参附件1）。 第八条用户权限审批 《ERP权限新增/变更/注销申请表》由申请人提交，经所在部门领导、分管领导及质量信息部部门领导审批同意后，报送系统管理员。系统管理员根据申请人填写内容并与申请人以及部门领导沟通后，填写申请表中系统管理员之相应内容并存档。 第九条用户权限配置 用户权限审批通过后，系统管理员将在两个工作日内完成权限新增/变更/注销工作，并以电子邮件通知申请人以及部门领导。 第十条用户权限测试 申请人在接到权限开通通知后，须在三个工作日之内完成系统权限测试，如有问题可通过电子邮件（包含问题的文字说明及截图）反馈到系统管理员。系统管理员应及时给予解决，并将处理结果通过电子邮件及时反馈给申请人。 在三个工作日之内无问题反馈的，系统管理员将视此权限设置正确，后续如有问题将按照用户权限申请流程处理。
信息系统用户帐号与角色权限管理流程 一、目的 碧桂园的信息系统已经在集团下下各公司推广应用，为了确保公司各应用信息系统安全、有序、稳定运行，我们需要对应用信息系统用户帐号和用户权限申请与审批进行规范化管理,特制定本管理规定。 二、适用范围 适用于公司应用信息系统和信息服务，包括ERP系统、协同办公系统、各类业务应用系统、电子邮箱及互联网服务、数据管理平台等。 三、术语和定义 用户：被授权使用或负责维护应用信息系统的人员。 用户帐号：在应用信息系统中设置与保存、用于授予用户合法登陆和使用应用信息系统等权限的用户信息，包括用户名、密码以及用户真实姓名、单位、联系方式等基本信息内容。 权限：允许用户操作应用信息系统中某功能点或功能点集合的权力范围。 角色：应用信息系统中用于描述用户权限特征的权限类别名称。 四、用户管理 （一）用户分类 1.系统管理员：系统管理员主要负责应用信息系统中的系统参数配置，用户帐号开通与维护管理、设定角 色与权限关系，维护公司组织机构代码和物品编码等基础资料。 2.普通用户：指由系统管理员在应用信息系统中创建并授权的非系统管理员类用户，拥有在被授权范围内 登陆和使用应用信息系统的权限。 （二）用户角色与权限关系 1.应用信息系统中对用户操作权限的控制是通过建立一套角色与权限对应关系，对用户帐号授予某个角色 或多个角色的组合来实现的，一个角色对应一定的权限（即应用信息系统中允许操作某功能点或功能点 集合的权力），一个用户帐号可通过被授予多个角色而获得多种操作权限。 2.由于不同的应用信息系统在具体的功能点设计和搭配使用上各不相同，因此对角色的设置以及同样的角 色在不同应用信息系统中所匹配的具体权限范围可能存在差异，所以每个应用信息系统都需要在遵循《应 用信息系统角色与权限设置规范》基础上，分别制定适用于本系统的《碧桂园应用信息系统角色与权限
系统账户权限管理规范 1.目的 为规范产业公司系统账户、权限管理，确保各使用单位与权限操作间的有效衔接，防止账户与权限管理失控给公司带来利益损失、经营风险。信息系统帐号的合理配置、有效使用、及时变更、安全保密，特制订本规范。 2.适用范围 本规范适用于多公司本部各单位、营销机构。 3.定义 3.1公司：指多媒体产业公司 3.2单位：指公司下属各单位，包含HR中体现为不同人事范围的直属部门、驻外机构。 3.3人事管理：指负责本单位人事信息人员，包括行政机构、驻外分公司人事经理、事业部、生产厂等部门级人事管理岗。 3.4权限管理员：负责本单位信息系统用户集中申请、变更，管理本单位信息系统用户对口的管理人员。包含单位自行开发和管理的信息系统（自行开发系统由所在部门指定系统管理员负责），如营销中心的“DDS”，研究“PDM”也是流程申请的维一发起人。 3.5系统管理员：指系统开发、系统配置管理的IT人员，部分虹信IT顾问为主。也可根据组织架构授权给某业务单位的相关人员，其负责某系统用户和权限的配置管理者。 3.6系统流：指每个系统固定的申请、审批流，原则上由系统管理员或权限管理员配置。 4.部门职责 4.1产业公司负责人： 4.1.1.公司信息系统立项、验收等审批工作。 4.1.2.公司信息系统，信息安全的第一责任人。 4.1.3.公司信息系统组织第一责任人
4.2人事部门： 4.2.1负责在人力资源管理系统（以下简称HR系统）处理人事档案，各单位权限管理员提交的信息系统需求协助。 4.2.2提供各单位的入职、调动、离职信息给信息系统管理部门。 4.2.3协助信息系统部门与人事相关的其它需求。 4.3控制中心： 4.3.1负责发布和制定信息建设规范，并组织通过技术手段或辅助工具管理。4.3.2负责组织周期性清理各信息系统账户。 4.3.3负责信息系统档案的建立。 4.3.4负责信息系统维护、权限配置、权限审核等相关事宜。 4.3.5 4.4用户申请部门和使用单位: 4.4.1各单位第一负责人管理本单位员工，各信息系统账户、权限申请、审核并对信息系统安全负责。定期组织相关人员对部门的信息系统帐号、权限进行清理和检查，申请职责可指定单位专人负责。 4.4.2权限管理员作为各单位信息系统申请的唯一发起人。 4.4.3权限管理员协助单位人事向公司人事部提交本单位入职、调动、离职信息。 4.4.4权限管理员负责本单位员工，各信息系统账户的新增、变更、冻结以及对应系统权限的申请工作。 4.4.5权限管理员负责定期核查本单位员工，对应系统账户的权限，若有偏差及时发起变更申请流程。 4.4.6帐号使用者不得将自己权限交由它人使用，部分岗位因工作需要交由同部门使用时，必须保证其安全和保密工作。 4.5系统操作部门： 4.5.1系统管理员负责对权限管理员提交的申请进行权限操作、审核。 4.5.2系统管理员定期在系统或SSU上获取信息系统的账号、权限分布表，并进行检查，对发现问题和风险的帐号及时告知相关部门并发起相应流程。 4.5.3系统管理员负责对系统故障进行处理或提交集团。 4.5.4系统管理员负责对系统操作手册的解释和编制工作。
中国免疫规划信息管理系统用户与权限管理规范 一、总则 （一）目的 加强中国免疫规划信息管理系统管理，规范系统用户与权限，保障免疫规划信息管理系统的安全运行，特制定本规范。 （二）依据 《计算机信息系统安全保护条例》 《疫苗流通和预防接种管理条例》 《卫生系统电子认证服务管理办法（试行）》 《预防接种工作规范》 《儿童预防接种信息报告管理工作规范（试行）》 《全国疑似预防接种异常反应监测方案》 《中国疾病预防控制中心计算机网络安全管理办法（试行）》 （三）适用范围 “中国免疫规划信息管理系统”包括预防接种、疫苗管理、疑似预防接种异常反应、冷链设备4个业务管理子系统和综合管理系统。 本规范适用于使用“中国免疫规划信息管理系统”的所有机构和用户，包括各级卫生计生行政部门、疾病预防控制机构、乡级防保组织和预防接种单位、药品不良反应监测机构及其它有关机构和用户。 二、用户管理 （一）用户类型
1、系统管理员 国家、省、市、县级疾病预防控制机构设立系统管理员，授权管理“中国免疫规划信息管理系统”用户，是履行用户管理与服务职能的唯一责任人。 2、审计管理员 国家、省、市、县级疾病预防控制机构设立审计管理员，授权“中国免疫规划信息管理系统”安全审计，是履行系统安全审计的责任人。 3、业务管理员 国家、省、市、县级疾病预防控制机构设立业务管理员，授权分配业务子系统用户权限，是履行所管业务子系统的权限分配、建立角色等职能的责任人。 4、普通用户 各级根据业务需求，由系统管理员建立普通用户，由业务管理员授权，是执行相应业务工作的责任人。 （二）用户职责 1、系统管理员 负责本级的业务管理员、普通用户以及下一级系统管理员的用户账号管理，县级系统管理员还需负责辖区内乡级普通用户的账号管理。包括各类用户的创建、有效性及密码等维护管理，分配业务子系统，为所管用户提供账号使用的操作培训和技术指导等。 2、审计管理员 负责本级及下一级操作安全审计，县级审计管理员还需负责辖区
SVN 管理员使用指南
目录 1Subversion简介 (1) 1.1Subversion简介 (1) 1.2Subversion架构 (2) 1.3Subversion组件 (3) 1.4Subversion基本流程 (3) 2安装SVN 服务 (4) 2.1安装SVN和TortoiseSVN (4) 2.2创建SVN资源库 (4) 2.3创建SVNserver服务 (5) 2.4运行SVNserver服务 (6) 3用户及权限管理 (6) 3.1用户管理 (7) 3.2权限管理 (7) 4SVN基本使用 (9) 4.1导入/导出（import/export） (9) 4.2初始化检出（checkout） (10) 4.3更新修改（update） (10) 4.4查看日志信息（show log） (10) 4.5取消修改（revert） (10) 4.6提交修改（commit） (10) 4.7合并信息（merge） (10) 4.8创建/删除/重命名 (10) 4.9加锁/释放锁（get/release lock） (10) 4.10添加、删除、重命名（add、delete、rename） (10) 4.11拷贝（copy） (13) 4.12查看修改信息（check for modifications） (13) 4.13分支/标记（branch/tag） (13)
4.14创建并应用补丁（create/apply patch） (15) 4.15备份/恢复资源库 (17) 4.16删除资源库 (19) 4.17版本（revision）关键字 (19) 4.18统计信息（statistics） (20) 4.19禁用密码缓存 (21) 5TortoiseSVN设置 (21) 5.1常规设置（General） (23) 5.2图标叠加（Icon overlays） (27) 5.3网络设置（network） (29) 5.4日志缓存设置（log caching） (30) 5.5钩子脚本设置（Hook Scripts） (32) 5.6外部程序设置（external programs） (32) 6TortoiseSVN基本命令 (37) 6.1Svn子命令 (37) 6.2Svnadmin (38) 6.2.1Svnadmin Switches (39) 6.2.2Svnadmin Subcommands (39) 6.3Svnlook (40) 6.3.1Svnlook选项 (40) 6.3.2Svnlook (41) 6.4Svnserve (41) 6.4.1Svnserve选项 (41) 6.5Svnversion (42) 6.5.1Svnversion选项 (42)
系统用户及权限管理制度
航开发系统用户账号及权限管理制度 第一章总则 第一条 航开发系统用户的管理包括系统用户ID的命名；用户ID的主数据的建立；用户ID的增加、修改；用户ID的终止；用户密码的修改；用户ID的锁定和解锁；临时用户的管理；应急用户的管理；用户ID的安全管理等。 第二章管理要求 第二条 航开发系统管理员（以下简称系统管理员）在系统中不得任意增加、修改、删除用户ID，必须根据《系统用户账号申请及权限审批表》和相关领导签字审批才能进行相应操作，并将相关文档存档。 第三条 用户ID的持有人特别是共享的用户ID必须保证用户ID和用户密码的保密和安全，不得对外泄漏，防止非此用户ID的所有者登录系统。
第四条 用户管理员要定期检查系统内用户使用情况，防止非法授权用户恶意登录系统，保证系统的安全。 第五条 用户ID持有人要对其在系统内的行为负责，各部门领导要对本部门用户的行为负责。 第六条 用户ID的命名由系统管理员执行，用户ID 命名应遵循用户ID的命名规则，不得随意命名。 第七条 用户ID主数据库的建立应保证准确、完整和统一，在用户ID发生改变时，用户管理员应及时保证主数据库的更新，并做好用户ID变更的归档工作。 第八条 对用户申请表等相关文档各申请部门的用 户管理员必须存档，不得遗失。 第九条
公司NC-ERP系统中各部门必须明确一名运维管理人员负责本部门用户管理、权限管理及基础数据维护等相关工作。 第三章增加、修改用户ID的管理 第十条 公司NC-ERP系统中增加、修改用户ID应符合下列情况之一： 1、因工作需要新增或修改用户ID； 2、用户ID持有人改变； 3、用户ID封存、冻结、解冻； 4、单位或部门合并、分离、撤消； 5、岗位重新设置； 6、其他需要增加或修改公司NC-ERP系统中 用户ID的情况。 第十一条 用户ID的增加、修改，须由申请人填写《NC-ERP用户账号申请表》，所在部门主管签字审批后，系统管理员审查并报主管领导审批后执行相应的操作。 第四章用户ID终止的管理
XX医院 应用信息系统用户帐号与角色权限管理办法 （讨论版） 新津县妇幼保健院信息科 二○一五年四月
目录 2 适用范围............................................................ 3 术语和定义.......................................................... 4 用户管理............................................................ 用户分级............................................................ 用户分类............................................................ 用户角色与权限关系.................................................. 用户帐号实名制注册管理.............................................. 5 用户帐号申请与审批.................................................. 帐号申请............................................................ 帐号审批和开通...................................................... 6 安全管理............................................................ 帐号安全........................................................... 密码安全........................................................... 信息安全........................................................... 7 档案管理............................................................ 附表1应用信息系统角色与权限关系对照表（表样）......................... 附表2用户帐号申请单................................................... 附表3用户帐号批量申请单............................................... 附表4用户帐号管理工作登记表........................................... 1目的 为加强新津县妇幼保健院信息科计算机中心（以下简称：中心）应用信息 系统用户帐号和用户权限申请与审批的规范化管理,确保中心各应用信息系统 安全、有序、稳定运行，特制定本管理办法。
信息系统权限分级管理制度 为了进一步规范我院的信息系统使用，保障网络信息系统安全，特制定本制度。 一、分级操作原则与级别划分 根据对信息系统安全性的威胁程度，以及各部门对电脑系统的应用需要，进行分级。对我院信息系统操作人员划分为以下级别: 1级：全局管理员，对医院信息化网络享有全面权限的人员。 本级权限由院信息化领导小组授权信息科科长，可对我院信息系统因业务需要开展的新建、部署、维护等各方面工作。 2级：专业管理员，具体包括： 2.1包括软件系统管理员：享有对操作系统及应用系统进行安装调试、修复、应用软件测试、部署、版本控制、文档等职能。 本权限由信息科赋予指定专人负责，在1级权限所有人指导与批准下开展工作。 2.2数据库管理员：享有对数据库系统的操作、备份、调整、测试等权限。 本权限由信息科科长指定专人负责，在1级权限所有人指导与批准下开展工作。 2.3操作员授权管理员：享有对操作系统、数据库系统、应用软件按规定流程设定操作权限的权利 本权限由信息科赋予指定专人负责，在1级权限所有人指导与批准下开展工作。 2.4网络授权管理员：享有对网络设备及网络管理软件的操作、备份、调整、测试等权限。 本权限由信息科赋予指定专人负责，在1级权限所有人指导与批准下开展工作。 3级：字典维护员，对信息系统中包括床位、费用、药剂、材料等基础数据字典按规定进行维护的权限，具体包括： 3.1诊疗维护员：享有对各项医技、治疗、材料等诊疗收费字典按规定进行新增、调价、变更、废止等权限。
本权限由信息科指定专人负责，经正常手续由2.3级权限所有人进行软件授权后开展工作。 3.2药品维护员：享有对西药、成药、草药等常规字典按规定进行新增、调价、变更、废止等权限 本权限由药剂科指定专人负责，经正常手续由2.3级权限所有人进行软件授权后开展工作。 3.3其他字典维护员：享有对除诊疗与药品之外的其他字典如床位、患者类别、付费方式等按规定进行新增、变更、废止等权限。 本权限由信息科指定专人负责，经正常手续由2.3级权限所有人进行软件授权后开展工作。 4级：部门管理员，部门主管或指定人员享有因本部门业务需要的部门及管理权限，具体包括： 1）门诊收费管理员：发票管理、重打印由于软件或硬件原因造成的错误单据、部门工作统计与审核等，本权限赋予门诊收费处指定人员。 2）药房、药库管理员：药品库存管理、部门工作审核等，本权限赋予药房及药库指定人员。 3）结账室收费管理员：住院发票及预交金数据管理、重打印由于软件或硬件原因造成的错误单据、部门工作统计与审核等，本权限赋予结账室指定人员。 4)其他部门管理人员：享有对本部门工作的信息系统数据审核、查询等权限的人员，由各部门领导或其指定人员享有。 5级：业务操作员，直接在电脑终端应用系统上进行包括门诊、医技、药剂、住院、护理等相关工作的普通工作人员。 本级人员包括除上述1-4级权限之外的所有电脑应用操作人员。 二、人员授权原则 在为操作人员分配权限时应遵循以下原则： 1）1、2级权限享有人不得同时享有3、4级权限；
系统账户权限管理规范 1.目的为规范产业公司系统账户、权限管理，确保各使用单位与权限操作间的有效衔接，防止账户与权限管理失控给公司带来利益损失、经营风险。信息系统帐号的合理配置、有效使用、及时变更、安全保密，特制订本规范。 2.适用范围本规范适用于多公司本部各单位、营销机构。 3.定义 3.1公司：指多媒体产业公司 3.2单位：指公司下属各单位，包含HR中体现为不同人事范围的直属部门、驻外机构。 3.3人事管理：指负责本单位人事信息人员，包括行政机构、驻外分公司人事经理、事业部、生产厂等部门级人事管理岗。 3.4权限管理员：负责本单位信息系统用户集中申请、变更，管理本单位信息系统用户对口的管理人员。包含单位自行开发和管理的信息系统（自行开发系统由所在部门指定系统管理员负责），如营销中心的“ DDS”，研究“ PDM”也是流程申请的维一发起人。 3.5系统管理员：指系统开发、系统配置管理的IT 人员，部分虹信IT 顾问为主。也可根据组织架构授权给某业务单位的相关人员，其负责某系统用户和权限的配置管理者。 3.6 系统流：指每个系统固定的申请、审批流，原则上由系统管理员或权限管理员配置。 4.部门职责 4.1产业公司负责人： 4.1.1.公司信息系统立项、验收等审批工作。 4.1.2.公司信息系统，信息安全的第一责任人。 4.1.3.公司信息系统组织第一责任人 4.2人事部门：
4.2.1负责在人力资源管理系统（以下简称HR 系统）处理人事档案，各单位权限管理员提交的信息系统需求协助。 4.2.2提供各单位的入职、调动、离职信息给信息系统管理部门。 4.2.3协助信息系统部门与人事相关的其它需求。 4.3控制中心： 4.3.1负责发布和制定信息建设规范，并组织通过技术手段或辅助工具管理。 4.3.2负责组织周期性清理各信息系统账户。 4.3.3负责信息系统档案的建立。 4.3.4负责信息系统维护、权限配置、权限审核等相关事宜。 4.3.5 4.4 用户申请部门和使用单位: 4.4.1各单位第一负责人管理本单位员工，各信息系统账户、权限申请、审核并对信息系统安全负责。定期组织相关人员对部门的信息 系统帐号、权限进行清理和检查，申请职责可指定单位专人负责。4.4.2权限管理员作为各单位信息系统申请的唯一发起人。 4.4.3权限管理员协助单位人事向公司人事部提交本单位入职、调动、离职信息。 4.4.4权限管理员负责本单位员工，各信息系统账户的新增、变更、冻结以及对应系统权限的申请工作。 4.4.5权限管理员负责定期核查本单位员工，对应系统账户的权限，若有偏差及时发起变更申请流程。 4.4.6帐号使用者不得将自己权限交由它人使用，部分岗位因工作需要交由同部门使用时，必须保证其安全和保密工作。 4.5 系统操作部门： 4.5.1系统管理员负责对权限管理员提交的申请进行权限操作、审核。 4.5.2系统管理员定期在系统或SSU 上获取信息系统的账号、权限分布表，并进行检查，对发现问题和风险的帐号及时告知相关部门并发起相应流程。
航开发系统用户账号及权限管理制度 第一章总则 第一条 航开发系统用户的管理包括系统用户ID的命名；用户ID的主数据的建立；用户ID的增加、修改；用户ID的终止；用户密码的修改；用户ID的锁定和解锁；临时用户的管理；应急用户的管理；用户ID的安全管理等。 第二章管理要求 第二条 航开发系统管理员（以下简称系统管理员）在系统中不得任意增加、修改、删除用户ID，必须根据《系统用户账号申请及权限审批表》和相关领导签字审批才能进行相应操作，并将相关文档存档。 第三条 用户ID的持有人特别是共享的用户ID必须保证用户ID和用户密码的保密和安全，不得对外泄漏，防止非此用户ID的所有者登录系统。 第四条 用户管理员要定期检查系统内用户使用情况，防止非法授权用户恶意登录系统，保证系统的安全。 第五条 用户ID持有人要对其在系统内的行为负责，各部门领导要对本部门用户的行为负责。
第六条 用户ID的命名由系统管理员执行，用户ID命名应遵循用户ID的命名规则，不得随意命名。 第七条 用户ID主数据库的建立应保证准确、完整和统一，在用户ID发生改变时，用户管理员应及时保证主数据库的更新，并做好用户ID变更的归档工作。 第八条 对用户申请表等相关文档各申请部门的用户管理员必须存档，不得遗失。 第九条 公司NC-ERP系统中各部门必须明确一名运维管理人员负责本部门用户管理、权限管理及基础数据维护等相关工作。 第三章增加、修改用户ID的管理第十条 公司NC-ERP系统中增加、修改用户ID应符合下列情况之一： 1、因工作需要新增或修改用户ID； 2、用户ID持有人改变； 3、用户ID封存、冻结、解冻； 4、单位或部门合并、分离、撤消； 5、岗位重新设置； 6、其他需要增加或修改公司NC-ERP系统中用户ID的情况。 第十一条
SVN权限控制解析 作为一个配置管理员，需要管理用户的权限，本文主要介绍了如何使用Subversion的授权文件“authz-db”，同时为了叙述的清晰，我首先澄清一些概念。 1、认证(Authentication）和授权(Authorization） 这两个术语经常一起出现。其中认证的意思就是鉴别用户的身份，最常见的方式就是使用用户名和密码，授权就是判断用户是否具备某种操作的权限，在Subversion里提供了“authz-db”文件，实现了以路径为基础的授权，也就是判断用户是否有操作对应路径的权限，在Subversion 1.3之后，svnserve和Apache一样都可以使用“authz-db”文件。 2、svnserve下的配置文件 因为本文是以svnserve为例的，所以先介绍一下版本库目录的结构： 其中conf下面有三个文件： 其中的“svnserve.conf”是这个版本库的配置文件，当使用svnserve时，
上面的配置说明： 1、匿名用户的权限为none(可以为none、read、write） 2、认证用户的权限为write(可以为none、read、write。SVN的权限 认证方式是基于此处的设置和anthz授权文件中的设置，两者都满足 (&方式)才成立，即 read&read=read,read&write=read,write&write=write,所以 此处应把认证用户的权限设置为write，否则authz文件中关于写权 限的设置都会无效的 3、使用了“svnserve.conf”同目录的passwd和authz，其中的 password-db指定了用户密码文件，authz-db是我们的授权文件， 也就是我们本文主要介绍的文件。 4、realm为“My First Repository”，这个值作为客户端保存服务器端 信息(如用户和密码)的唯一识别符 注意：使用Apache作为服务器时，根本就不会参考“svnserve.conf”文件的内容，而是会参考Apache的配置。 3、基于svnserve的版本库文件布局 使用svnserve时，为了管理的方便，应该使用相同的认证和授权文件，所以应该让所有版本库的配置文件svnserve.conf指向同一个password-db和authz-db文件。下面是一个多版本库的目录：
================ Subversion之路 ================ ---------------------------- 实现精细的目录访问权限控制 ---------------------------- :作者: 郑新星 :联系: zhengxinxing gmail
******股份有限公司 信息系统权限及数据管理办法（试行） 第一章总则 第一条为了加强对******股份有限公司（简称：公司）各运行信息系统权限和数据的管理，明确权限及数据管理相关责任部门，提高信息系统的安全运行和生产能力，规范公司业务系统权限申请及数据管理流程，防范业务系统操作风险，公司制定了信息系统权限及数据管理办法，以供全公司规范执行。 第二条本办法所指信息系统权限及数据包括，但不仅限于公司运行的OA 办公系统、业务作业系统、对外网站系统等涉及的系统用户权限分配、日常管理、系统及业务参数管理，以及数据的提取和变更。 第三条本办法遵循责权统一原则对员工进行系统授权管理，控制公司相关信息传播范围或防范进行违规操作。 第四条信息技术部是本办法主要执行部门，设立系统运维岗负责系统用户权限管理、部分基本参数设置、系统数据的提取和变更的具体技术实现。其它相关部门应指定专人（简称：数据权限管理员）负责统一按本办法所制定的流程执行相关操作，或通过工作联系单方式提出需要信息技术部或其它相关部门完成的具体工作内容。 第五条用户授权和权限管理应采取保守原则，选择最小的权限满足用户需求。 第二章系统权限管理 第六条系统权限管理由信息技术部系统运维岗和各业务部门数据权限管理员共同协作完成，风险与合规部数据权限管理员负责对业务部门提出的系统权限进行审批，信息技术部系统运维岗负责对权限进行变更。信息技术部系统运维岗拥有系统管理和用户管理权限（信息技术部可以拥有开发测试环境超级用户权限），风险与合规部拥有超级用户权限，风险与合规部数据权限管理员拥有对权限列表进行查询的权限，以方便行使监督职能。
国网统一身份管理系统单点登录和身份同步接入规范 项目名称<国网统一身份管理系统> 文档类别<接口规范> 文档编号<> 版本<> 密级<> 二〇二〇年八月十七日
目录 一、国网统一身份管理系统介绍 (3) 1.1 系统概述 (3) 1.2 单点登录流程 (4) 1.3 单点登录接入方式 (5) 二、国网应用系统单点登录集成 (6) 2.1国网应用系统集成分类 (6) 2.2应用系统权限管理模式 (7) 2.3单点登录集成要求 (9) 2.4 单点登录集成流程 (12) 三、身份同步规范 (15) 3.1用户身份数据流 (15) 3.2帐号管理流程 (16) 3.2.1帐号创建流程 (16) 3.2.2帐号更新流程 (16) 3.2.3帐号删除/禁用流程 (16) 3.3帐号的身份同步 (17) 3.4数据库改造 (17)
一、国网统一身份管理系统介绍 1.1 系统概述 单点登录 目录系统 管理模块 应用系统认 应用系统 由上图可见国家电网统一身份管理系统由单点登录和目录管理两部分构成。其中单点登录采用的是Novell的单点登录产品Access Manager，其单点登录通过Access Manager访问网关、单点登录认证管理模块、认证目录三部分协作实现。统一身份管理系统中的目录包含三类：认证目录、资源目录和身份目录。 认证目录是专用于Novell Access Manager做用户认证使用的目录，目录中包含所有登录总部门户的用户。用户核心属性是用户名、密码以及单点登录到应用系统的帐号和密码。 资源目录是国网总部部门数据以及应用权限数据的权威数据源。在该目录下管理用户所属的组织机构信息、各应用系统的信息、各应用系统的分组角色信息等。组织机构信息、应用系统信息、分组角色信息等可供各应用系统认证管理模块做权限管理。资源目录中的用户核心属性是用户名、OU。 身份目录是国网用户的权威数据源。所有国网总部的用户都从身份目录中开始创建、修改、删除。该目录下的用户具有最全面的用户信息，它实时向认证目录和资源目录中同步用户信息。
SVN用户权限管理讲解 /***********************************************************/ //SVNSubversion 用户权限管理//资料来源：网络、总结//2010年7月20日 /***********************************************************/ 基本的操作：以我创建的Svn工程为例子来讲解SVN权 /***********************************************************/ //SVNSubversion 用户权限管理 //资料来源：网络、总结 //2010年7月20日 /***********************************************************/ 基本的操作： 以我创建的Svn工程为例子来讲解SVN权限管理的配置 仓库创建路径：D:\SVNLibrary >>>取消匿名登陆： 打开文件D:\SVNLibrary\conf\svnserve.conf 找到：###anon-access = read 将前面的注释去掉，并将read 改为：none 即使：anoe-access=none 表示匿名登陆下的用户权限为空。即：系统不支持匿名登陆 说明： auth-access = write #通过验证的用户可以读和写 auno-access = read #匿名登陆下可以只读文件，即：文件修改后无法提交到服务器 password-db =password #用户保存文件的名称 authz-db =authz #权限管理文件这个是非常重要的，如果我们要对整个工程的文件进行权限分配的时候，就必须将这个行文件前面注释掉，否咋即使我们在权限配置文件里面进行再多的配置都是无效的。这点我已经犯错了。 然后我们在authz 文件下面进行权限的分配 在权限分配的时候要注意的问题： >>>权限分配时，应遵守从根目录到子目录、从设置最广泛权限到最精细权限、从只读权限到读写权限设置原则，即从根目录开始设置最广泛的访问权限，然后逐步设置下属子目录的访问权限。提示：目录的访问权限既可以分配给组，也可以分配指定用户。 >>>对某个用户，如果只赋给他某个目录的权限，但对上级目录没有赋给，则他不能有上级目录的任何权限 例如某个用户有：/repository/project1的r权，而没有/repository的r权 >>>对于所有的目录，都优先处理设置在这个目录上的权限设置。 例如sai用户： [/repository] sai = rw 对于repository目录，他有rw的权限。 [/repository/project1] sai = r 对于repository下的project1目录，他只有r权限。