Comparison of OS-defined groups and ACL authorization

OS-defined groups

In version 8.0 and earlier ClearCase® releases, each VOB element has three protection categories: owner, group, and other. For each category, the administrator can set or clear the read and execute bits. For example, if you have a source file that should be readable to the owner and members of the element group, but not to all users in the network, then you would set owner=read, group=read, other=none. If you have an executable file for some programming tool, you might set all three to read and execute.

In practical terms, this model requires you to use a separate group for each class of elements that shares the same protection. If you do not permit all users to read elements in your VOB, then you set other=none and must control access using the owner and group categories.

The element owner has only limited usefulness in element protection, leaving only the group as an effective control. An element's owner is by default set to the user account that created the element. If you have multiple developers, then the elements' owners will vary, which is not convenient for access control. Some administrators configure a trigger to change ownership to the VOB owner account after element creation, but this is also inconvenient for access control since most users seldom assume the identity of the VOB owner

That leaves the element's group as the mechanism to control access to each element. The administrator must define a separate group for each class of element needing protection. For example, element class 1 is for developers of component A. Element class 2 is for developers of component B. Element class 3 is for all developers (shared code). If you have 25 components (A-Y) and one shared component (Z), you need 26 groups to control access. You would protect all elements in component A as readable to group A but not world readable. Likewise for components B-Y. Each developer of component A-Y would be a member of that group, plus also a member of group Z. The account used to build and integrate all the code needs to be a member of all groups A-Z.

The groups used by ClearCase are defined by the operating system (Windows Domain, Linux or UNIX NIS or LDAP) and added to a user's credentials when he/she logs into a host running ClearCase. Unfortunately, due to limitations in the network protocols used in the operating system and in ClearCase, a single user can only use 16 groups (UNIX and Linux) or 32 groups (Windows) at a time with ClearCase. In the example above, the build/integrate account needs to use 26 groups to complete the build—necessitating either some complex sequencing of build steps and credentials changes defining which groups are activated for ClearCase or compromising on the implementation of your element security and using fewer element classes/groups. Neither option is desirable.

ACLs on elements

If you enable ACLs for protection of elements in a Feature Level 8 VOB in ClearCase 8.0.1, you can change your access control strategy to eliminate many cases where you would hit the per-user group membership limits. It might help to think of ACLs as enabling you to put elements into multiple groups instead of having to put users into multiple groups. Because the number of groups that are allowed in an element effective ACL is not limited to the same low limits as the number of groups for a user account, this security mechanism enables some new protection use cases and simplifies others.

With ACLs on elements, you can grant access to multiple individual users, multiple groups, and a few categories of "everyone". This topic discusses ACLs on elements in terms of their effective ACLs. In this and related topics are examples of how rolemaps and policies combine to generate effective ACLs.

In the example above, there were 25 components A-Y, each to be accessed by a different team and by a build account ("builders"), but nobody else should have access. With ACLs, you would protect every element in a given component with a shared effective ACL that granted Change permissions to groupA and to builders.

Each other component B-Y would have a similar effective ACL. Component Z (the shared component) also has a similar effective ACL. In this configuration, each team member's account is in the corresponding group for their component, plus the group for Z (as before). But the builder account only needs to be in the "builders" group. You do not run into limits on simultaneous group membership for the builder account.

You also do not have to use complex strategies during a system build nor compromise on the security for components A-Y. You also gain flexibility to add additional groups and read-only access to elements. Suppose that component Z is maintained by its own team but should only be referenced by teams A-Y and you put the non-Z developers into group "alldevelopers" instead of "groupZ". You can configure component Z's element ACL so that groupZ has Change permissions, alldevelopers have Read permissions and builders have Change permissions.

A developer on team A will be able to read elements in component Z but not modify them. (Without ACLs, this would require a pre-operation checkout and mkbranch trigger to check the permission to modify the element, and reject an operation if not authorized.)

You can also put individual accounts into element ACLs. This might make sense if there are a few individuals that need specific access to a component, in a case where it is not worthwhile to create a new operating system group just for this purpose. So if component B should be modifiable by its team, plus another user ("extrauser"), the ACL would grant Change permissions to groupB, extrauser, and builders.

If you have some components that are maintained by multiple teams, you might even be able to eliminate some groups used previously. Suppose that component E was maintained by all the team members for components C and D. In the 8.0 example, you needed group E to contain all the members of both groups C and D. With ACLs, you can set up the ACL for component E to name both groups, then abandon the use of group E (remove it from the group list for accounts on teams C and D).

A policy and associated rolemaps

The foregoing description talks in terms of effective ACLs. In a VOB, the effective ACL is generated by applying a rolemap to a policy. The VOB database computes and caches the effective ACL for each rolemap. Each element is associated with a rolemap. To implement the above examples, you will need a distinct rolemap for each class of elements (components A - Z). You can link all these rolemaps to a single policy that describes your general protection model. Below is an example policy and set of rolemaps that yield the effective ACLs shown above. (In practice, you would probably want to add an administrative user or group to have Full control over all elements.)