要资料 文章 文库 视频 Code iProcess 课程 认证 咨询 工具 讲座吧   专家招募  
会员   
 
  
每天15篇文章
不仅获得谋生技能
更可以追随信仰
 
 
 
   
分享到
使用 ClearCase 8.0.1 实现有效的用户权限管理
 
火龙果软件    发布于 2014-04-17
 

本文主要介绍了 ClearCase 8.0.1 的新特性 ACLs。主要介绍了 ACLs 模式的基本概念以及如何应用 ACLs 新特性。笔者希望通过本文能让读者认识 ACLs 并运用到实际场景中。

ClearCase 8.0.1 ACLs 模式的基本介绍

在 ClearCase v8.0.1 之前的版本,ClearCase 通过操作系统的用户管理机制或者是通过 ClearCase 的触发器使用用户自定义的脚本来实现用户权限管理。

Rational ClearCase v8.0.1 加入了访问控制列表 Access Control List(ACL)的属性,通过 ACLs 来实现有效的用户权限管理。用户可以更灵活地去为 VOB 的元素分配和管理访问权限。同时,用户也获得更细颗粒度的访问模型,允许只读访问和独立控制各种类型的元素修改。

ACLs 模型简介

ClearCase 8.0.1 VOB 的 ACLs 模式通过在 VOB 里定义的两种类型的对象来管理:policy 和 rolemap。 每个 rolemap 都关联到一个 policy。所有的 policy 和 rolemap 用 Principals 来识别用户。ClearCase 8.0.1 版本实现了对 VOB、element、policy 和 rolemap 的 ACLs 控制,对于 UCM metadata type,会在以后的版本里实现。

Principal 的定义:Principal 是访问控制入口 Access Control Entry(ACE)的身份识别部分。Principal 可以有几种形式:Role、User 和 Group。Role 是用户自定义的所需要的职责,User 是指某个指定用户,而 Group 是指某个特定用户组。

policy 的定义:policy 由四个部分组成 VOB、policy、rolemap 和 element。即 policy 用于定义每个 clearcase VOB 里,各种用户类型对于整个 VOB, 以及 VOB 里 policy、rolemap 和 element 的访问控制策略。每个部分即 VOB、policy、rolemap、element 都指定了各自的 ACLs,每一组 ACLs 包含了一系列的访问控制入口(ACEs)以下简称 ACEs。每一条 ACE 指定了用于识别身份的 principal 和对应这个身份的权限。大多数情况下,policy 里会以 Role 这种类型的 principal 来定义访问策略。当然我们也可以在 policy 里直接使用 User 和 Group 这种类型的 principal 来直接对应访问策略。比如用户需要在 policy 里指定 Developer 这种角色对于 VOB、policy、rolemap 以及 element 各个对象的访问权限是 Read,或 Change, 或 Full 或其他。图 1 为一个简单 policy 的定义以及各个部分的含义。

图 1

rolemap 的定义:rolemap 用于定义用户在 policy 里定义的各个 Role 所对应的用户或组。比如,用户在 policy 定义了 Developer 组,那么在 rolemap 里就需要定义 Developer 组具体对应那些用户或组。

通过 rolemap 和 policy 的组合产生了对各个对象的有效的 ACLs 访问方式 Effective ACLs(以下简称 EACLs)。EACLs 列出了被授权的各个账户和组以及他们对于各个对象的访问权限。当用户试图访问一个 VOB、policy,、rolemap 或者一个 VOB 里的元素时,ClearCase 会检查角色映射控制的 EACLs, 验证当前用户是否有权限访问当前的对象。如果当前用户没有相关的授权,ClearCase 就会拒绝用户的操作动作。

policy 和 rolemap 的基本对应原理及示例

用户在建立新的 rolemap 的时候必须指定一个 policy。一个 policy 可以被一个或多个 rolemap 实现。正如上面一个章节提到,一个 rolemap 和 policy 的组合形成一个 EACLs。如果一个 policy 被多个 rolemap 实现,那么用户一旦修改这个 policy,每个之前生成的 EACLs 都会被修改。

图 2 展示了一个 policy 和一个 rolemap 的组合如何保护一个对象

图 2

图 3 展示了被两个 rolemap 实现的 policy 如何保护对象

图 3

下面就一个简单的场景来说明如何设计自己需要的 ACLs。

例如有两个团队 A 和 B 使用同一个 ClearCase VOB 来管理自己的源代码。两个团队的成员角色基本一样,都有 Manager、Developer、Tester、Administrator、Integrator 几种角色,只是每个角色对应的具体人有所不同。这两个团队对 VOB 里各个对象的访问策略也基本一致,比如开发角色对代码有写权限,但测试团队只有只读权限等。在这种场景下,我们就完全可以采取图二的这种 ACLs 设计模式,设计一个 policy,用两个不同的 rolemap 去实现。

policy 示例 Policy_Sample

[vob]
Role:Manager Read
Role:Developer Read
Role:Administrator Full
Role:Integrator Read

[element]
Role:Developer Change
Role:Tester Read
Role:Manager Read
Role:Integrator Change
Role:Administrator Full

[rolemap]
Role:Manager Read
Role:Developer Change
Role:Tester Read
Role:Integrator Read
Role:Administrator Full

[policy]
Role:Manager Read
Role:Developer Change
Role:Tester Read
Role:Administrator Full

这里需要说明,在 policy 里,我们可以指定一些操作的集合如 Read, Change, Full 等,也可以指定更细颗粒度的操作的名称。对于每个操作集合 Read, Change, Full 所对应的具体操作请参考第三章。这里简单举例对于 element 这种类型的对象,我们可以指定的具体操作有:read-info, lookup-dir, AclRead, mod-props, mod-checkout, mod-branch, write-dir, mod-task, mod-attr, mod-hlink, mod-trig, chmaster, rmver, mod-label, lock, AclWrite, Delete 等。

在本例中,对于 rolemap 里的职责映射, 同一个职责可以指向不同的用户或组。如 Role:Manager 职责就指向了不同的用户。也可以指向同一个用户,如 Role:Administrator,都指向了 user001 用户。当然,对于同一个用户或组,也可以被映射到不同的职责,在本例中没有体现,但在实际应用时完全可以把 user001 在 Rolemap_TeamA 中对应到 Role:Administrator,而在 Rolemap_TeamB 中对应到 Role:Manager。这个取决于用户的实际情况。

团队 A 的 Rolemap_TeamA:

Role:Administrator --> User:cn.ibm.com/user001
Role:Manager --> User:cn.ibm.com/Mgr_a
Role:Developer -->Group:cn.ibm.com/Dev_a
Role:Integrator --> User:cn.ibm.com/Inte_a
Role:Tester --> Group:cn.ibm.com/Tester_a

团队 B 的 Rolemap_TeamB:

Role:Administrator --> User:cn.ibm.com/user001
Role:Manager --> User:cn.ibm.com/Mgr_b
Role:Developer -->Group:cn.ibm.com/Dev_b
Role:Integrator --> User:cn.ibm.com/Inte_b
Role:Tester --> Group:cn.ibm.com/Tester_b

创建 Rolemap_TeamA 和 Rolemap_TeamB 的时候都指定同一个 policy 即 Policy_Sample,这样 Rolemap_TeamA 和 Rolemap_TeamB 的 EACLs 的列表如下:

rolemap "Rolemap_TeamA"
effective access control lists:
vob ACLs: User:cn.ibm.com/user001 Full
User:cn.ibm.com/Mgr_a Read
Group:cn.ibm.com/Dev_a Read
User:cn.ibm.com/Inte_a Read
element ACLs:
User:cn.ibm.com/Mgr_a Read
Group:cn.ibm.com/Dev_a Change
User:cn.ibm.com/Inte_a Change
Group:cn.ibm.com/Tester_a Read
User:cn.ibm.com/user001 Full
policy ACLs: User:cn.ibm.com/user001 Full
User:cn.ibm.com/Mgr_a Read
Group:cn.ibm.com/Dev_a Change
Group:cn.ibm.com/Tester_a Read
rolemap ACLs: User:cn.ibm.com/user001 Full
User:cn.ibm.com/Mgr_a Read
Group:cn.ibm.com/Dev_a Change
User:cn.ibm.com/Inte_a Read
Group:cn.ibm.com/Tester_a Read
rolemap "Rolemap_TeamB"
effective access control lists:
vob ACLs: User:cn.ibm.com/user001 Full
User:cn.ibm.com/Mgr_b Read
Group:cn.ibm.com/Dev_b Read
User:cn.ibm.com/Inte_b Read
element ACLs:
User:cn.ibm.com/Mgr_b Read
Group:cn.ibm.com/Dev_b Change
User:cn.ibm.com/Inte_b Change
Group:cn.ibm.com/Tester_b Read
User:cn.ibm.com/user001 Full policy ACLs: User:cn.ibm.com/user001 Full
User:cn.ibm.com/Mgr_b Read
Group:cn.ibm.com/Dev_b Change
Group:cn.ibm.com/Tester_b Read
rolemap ACLs: User:cn.ibm.com/user001 Full
User:cn.ibm.com/Mgr_b Read
Group:cn.ibm.com/Dev_b Change
User:cn.ibm.com/Inte_b Read
Group:cn.ibm.com/Tester_b Read

几种创建 rolemap 和 policy 的方法及简单例子

我们可以通过两种方法去创建需要的 rolemap 和 policy:命令行或图形界面。下面就这两种方法做简单介绍。

命令行

用命令行创建 rolemap 和 policy 之前需要事先写好 rolemap 和 policy 文件。在本文的例子中,我们可以把上节的 policy 示例的内容放到一个文件中 Policy_Sample.acl,把团队 A 的 Rolemap_TeamA 的示例内容放到文件 Rolemap_TeamA.acl, 团队 B 的

Rolemap_TeamB 的示例内容放到文件 Rolemap_TeamB.acl,将文件放到用户能访问的路径通过以下命令创建

步骤一:创建 clearcase 视图并进入到 VOB 目录

图 4

步骤二:创建 policy

图 5

步骤三:创建 rolemap

图 6

步骤四:查看 EACLs

图 7

图形界面

除了命令行,我们也可以通过 CTE 的图形界面创建和修改 policy 和 rolemap。我们可以通过点击左侧树形的 Policies 目录的右键菜单创建新的 policy,通过 Edit policy 窗口的 Add Principal 按钮创建新的 principals, 勾选不同的 permissions 选择各个职责需要的权限,如下图 8 所示:

图 8

对于 rolemap 的编辑也同理,如图 9 所示:

图 9

在修改 rolemap 和 policy 时所需要注意的一点。我们首先需要确定被修改的 rolemap 或 policy 是被哪个 rolemap 保护。去修改的用户在这个 rolemap 里有没有在 rolemap 或 policy 的部分里被授予写权限。比如 user002 想要去修改 Rolemap_TeamA,经查看,Rolemap_teamA 本身被 DefaultRolemap 所保护,但在 DefaultRolemap 的[rolemap]部分并没有对 user002 授予修改的权限,那么 user002 修改 Rolemap_TeamA 就会失败。

另外,在设置 ACLs 的时候如果意外把 VOB owner 自己排除在应有的权限之外了,ACLs 的重新获得机制可以帮助用户重新获得权限。设置环境变量 CCASE_ACL_RECOVERY_MODE=true 可以开启 ACLs 的重获机制。当 ACLs 重获机制打开时,ClearCase 的超级用户如 root 或者 VOB owner 可以运行 lspolicy, chpolicy, lsrolemap, chpolicy 等命令,运行这些命令的时候将会越过基本的 ACLs 权限检查。这个功能可以帮助用户从一个意外的权限锁住中恢复过来。当需要的权限恢复的时候,要及时把环境变量 CCASE_ACL_RECOVERY_MODE 设回 false.

在 ACLs 激活的 VOB 上的元素保护

当一个 VOB 开启 ACLs 属性后,ClearCase 就会在用户操作 VOB 元素的时候检查 ACLs 属性。元素的访问权限由多个独立权限单元所控制。比如,一个用户有新建分支的权限(mod-branch)但他却没有给一个版本加标签的权限(mod-label)。

为了管理方便,所有的独立权限被分为三个访问级别的组,Read,Change,Full。这三个权限组是递增的。Change 权限组包含了所有 Read 组的权限,并且加入了更多权限如 mod-task。同样,Full 权限也是在 Change 权限的基础上加了更多的操作权限。用户在定义 policy 时可以指定某一组权限,或单个的权限或是他俩的组合。

图五展示了每个权限组的范围。Read 组包含了所有第一列的权限,Change 包含了第一列及中间一列的权限,Full 组包含了所有的权限。如图 10 所示

图 10

在所有 ACLs 属性打开的 VOB 上会带有默认的 policy 和 rolemap。用户在设计好了所需要的 rolemap 之后可以把自己 rolemap 应用到 VOB 元素上了。应用 rolemap 也同样可以用命令行或者图形界面。

命令行方式

用户需要进入 clearcase 视图,如图 11 所示

图 11

CTE 图形界面

用户可以点击需要修改 rolemap 的 VOB 元素,找到 Show Properties 菜单,找到相应的 ACLs 入口,例如本次想要修改的是 element 部分。点击 Change 按钮,通过 Browse 按钮找到自己需要应用的 rolemap,确定。如图 12 所示。

图 12

ClearCase 会检查角色映射控制的 EACLs, 验证当前用户是否有权限访问当前的对象。如果当前用户没有相关的授权,ClearCase 就会拒绝用户的操作动作。比如 Project_A 下的文件都被 Rolemap_TeamA 保护,Rolemap_TeamA 的 rolemap 只赋予了 Mgr_a 只读的权限,因此当 Mgr_a 用户试图检出 Project_A 下的某个文件时,ClearCase 就会抛出错误信息,如下:

图 13

反之,如果是具备修改权限的 Dev_a 用户去做检出操作,那么文件就会成功检出。

ClearCase 8.0.1 提供了多个独立权限单元,我们在授予 VOB 用户权限时具备了更大的灵活性。比如对于同一个 element, 我们可以授予某些用于只读权限,而另一些用户读写权限。在 ClearCase 引入 ACLs 之前,用户只能通过触发器调用客户自己写的脚本实现访问控制。

多 VOB 家族 ACLs 的管理技巧

对于一个 ClearCase 管理员来说,如果他正在管理多个 VOB 家族,那么他就可以在各个 VOB 之间拷贝 policy 和 rolemap。这样的操作能让你的 VOB 家族具备类似的访问控制风格。

命令 cleartool cppolicy 提供了从一个 VOB 拷贝 policy 到另一个 VOB 的功能。同理,cleartool cprolemap 可以实现从一个 VOB 拷贝 rolemap 到另一个 VOB。如果在同一个 VOB 里使用 cprolemap 命令,rolemap 和 policy 的关联信息将会被保留。但如果在 VOB 之间使用 cprolemap 命令拷贝 rolemap, 新的 rolemap 将会实现默认的 policy 即 DefaultPolicy.

如果想拷贝一个 policy 或者一个 rolemap,但又不想改变他们之间的关系(rolemap 和 policy 之间的实现关系)那么就可以把 policy 和 rolemap 的内容转存到一个文件,然后用这个文件作为新建 policy 和 rolemap 的输入。

比如这里要将 VOB /cc/vobs/sjyang_paper 里的Rolemap_TeamA 拷贝到 VOB /cc/vobs/sjyang_paper_target 下,并需要同时保留与之关联的 policy Policy_Sample:

图 14

拷贝 rolemap

图 15

结束语

本文介绍了 Rational ClearCase 8.0.1 的 ACLs 模式做了基本介绍,并举了若干例子以加深理解。希望能为使用 ClearCase 的用户在使用 ACLs 属性的时候提供一定的参考。

相关文章 相关文档 相关课程



每日构建解决方案
如何制定有效的配置管理流程
配置管理主要活动及实现方法
构建管理入门
配置管理流程
配置管理白皮书
CM09_C配置管理标准
使用SVN进行版本控制
配置管理实践
配置管理方法、工具与应用
多层次集成配置管理
产品发布管理
 
分享到
 
 
   


软件配置管理的问题、目的
软件配置管理规范
CQWeb 7.1性能测试与调优指南
为什么需要使用ClearCase
ClearCase与RTC的集成
利用ClearQuest 进行测试管理
更多...   


产品发布管理
配置管理方法、实践、工具
多层次集成配置管理
使用CC与CQ进行项目实践
CVS与配置管理
Subversion管理员

相关咨询服务
SCM启动咨询
SCM流程规范咨询
SCM评估性咨询


配置管理实践(从组织级到项目级)
通号院 配置管理规范与应用
配置管理日构建及持续集成
丹佛斯 ClearCase与配置管理
中国移动 软件配置管理
中国银行 软件配置管理
天津华翼蓝天科技 配置管理与Pvcs
 
 
 
 
 
每天2个文档/视频
扫描微信二维码订阅
订阅技术月刊
获得每月300个技术资源
 
 

关于我们 | 联系我们 | 京ICP备10020922号 京公海网安备110108001071号