Policies

Policies have an Access Control List (ACL) for each controlled VOB metatype (such as element, VOB object, policy, and rolemap).

The access control entries (ACEs) in a policy list a principal and its granted permissions. Principals in a policy are usually roles, with the name of the role defined by the administrator. You can also put in specific users or groups as well, but most administrators prefer to put them into the rolemaps implementing the policy.

You create new policies with the cleartool mkpolicy command. Permission to create policies is controlled by the VOB object's effective ACL. The policy contents are supplied in a file that contains a section for each controlled metatype, listing the ACEs for that metatype. Each VOB gets a default policy (DefaultPolicy) as the result of a chflevel or mkvob operation.

Note: DevOps Code ClearCase® does not support negative (deny) permissions in ACEs, only positive (grant) ACEs.

Here is an example of a default policy:

policy "DefaultPolicy"
  created 2012-06-26T09:36:54-04:00 by Tester Tester (tester0.user@qlnx004)
  "Predefined object to represent default policy."
  protected by rolemap: "DefaultRolemap"
  effective access for user "mbadzak": Read
  owner: tester0
  group: user
  contents:
    vob ACL:
      Everyone: rmelem,Read
      User:at1.com/tester0 Full
    element ACL:
      Owner-User: Full
      Owner-Group: rmver,mod-label,Change
    policy ACL:
      Owner-User: Full
      Everyone: Read
    rolemap ACL:
      Owner-User: Full
      Everyone: Read

The VOB owner has full permission if the specified environment variable (EV) CCASE_ACL_RECOVERY_MODE is set to TRUE or true. The element owner has full access to the object. Other users in the group can remove a version, attach and detach labels, and make changes to it. The default policy grants the policy/rolemap owner full permission to the policy/rolemap object. Other users can only read the policy/rolemap.

You modify policies with cleartool chpolicy to add or remove principals from a controlled metatype's ACL. Permission to modify a policy is controlled by the policy's rolemap (just like any other controlled object). You can see the effective ACL governing changes to a policy with cleartool describe -eacl policy:policy-name.

Policy modifications, made using either mkpolicy -replace or chpolicy, affect containers on the disk for all elements that are using a rolemap implementing the specified policy for ACL information. This may take a long time to execute if many elements are protected by such rolemaps. In a replicated environment with preserving replicas, importing an oplog with a policy modification modifies the containers on disk, and may also take a long time to execute.

Here's an example of a policy input file; you can use it input to the cleartool mkpolicy command
[vob]
user:DOMAIN/backup read
Role:Manager read
Role:Developer read
Role:Integrator read
Role:Administrator Full
[element]
user:DOMAIN/backup read
Role:Manager read
Role:Developer change
Role:Integrator change