本文主要介绍了 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

这里需要说明，在 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 属性的时候提供一定的参考。