Nonpreserving and permissions-preserving replicas

The term non-preserving refers to both non-preserving replicas and replicas that preserve permissions but not identities.

Each non-preserving replica in a VOB family must manage its own rolemaps and policies and the bindings of controlled objects to rolemaps. The behavior described below is designed to make it possible to manage ACLs and their effective permissions independently at each non-preserving replica.

Initial state - replica raised to FL8

In an existing VOB family of replicas at feature level 7 or lower, the initial policies, rolemaps, and controlled object bindings are created when the family feature level is raised to 8. Each non-preserving replica defines the default policy and default rolemap with the same permissions that would be seen in a new VOB created at FL8 by the importing user accounts. All controlled objects in such a replica are bound to the default rolemap.

Initial state - replica created at FL8

When a non-preserving replica is created from a mkreplica packet generated by a VOB at FL8 or higher, the existing rolemaps and policies defined at the generating replica are duplicated in the new replica. However, any User or Group entries in policies and rolemaps are substituted with the user and group of the account creating the new non-preserving replica. Each controlled object is bound to the same rolemap as in the generating replica. The result is a VOB with the same structural relationship between policies, rolemaps and the objects controlled by rolemaps, but with identity substitutions in the effective ACLs. After the non-preserving replica is created, the administrator can identify which controlled objects are bound to a rolemap, define a new rolemap to control those objects in the new replica, and reprotect those objects. Once the administrator has done this for all in-use rolemaps, the non-preserving replica will be ready for use.

Mastership differences

A non-preserving replica can modify the role bindings in any rolemap and the permissions granted in any policy, regardless of mastership of the policy/rolemap. However, it cannot switch a rolemap from implementing one policy to another policy unless it masters the rolemap and both policies. Also, a non-preserving replica must master any policy it removes. A non-preserving replica may modify the binding of a controlled object to its rolemap without mastering the object. Because it is possible to modify every rolemap and policy at a non-preserving replica, an administrator might be tempted to use the same rolemaps and policies at every replica and manage them independently. However, most administrators create separate rolemaps and policies at each replica. Using separate rolemaps/policies at each non-preserving replica makes it obvious that the protection is being managed independently of the other replicas. The other replicas' rolemaps/policies will be visible in a non-preserving replica.

Mapping policy principals and rolemap roles to a non-preserving replica

When creating a non-preserving replica or importing mkpolicy and mkrolemap oplogs to a non-preserving replica, the principals in the policy and the roles in the rolemap will be modified. If a principal in a policy has multiple User and Group entries, they will be replaced by a single User and Group entry for the account creating the non-preserving replica or running the syncreplica import. Similarly for rolemaps, multiple User and Group entries in a role will be replaced by a single User and Group. The resulting permissions in the policy's principal will be the union of the permissions for the multiple User and Group entries. For example, if one User had Read rights and another had Change rights, these will be mapped to Change. The combination Read, Change, and AclWrite will be mapped to Change and AclWrite. Example of policy in mastering replica:

policy "pol-01"
 2012-11-20T14:09:53-05:00 by Tester Tester (tester0.user@qvml087)
  master replica: original@/tmp/vob-03
  owner: tester0
  group: user
  contents:
    vob ACL:
      User:at1.com/tester0 Full
      Group:at1.com/aclgrp1 Read
    element ACL:
      User:at1.com/tester2 AclWrite,Change
      User:at1.com/tester9 Read
      Group:at1.com/aclgrp5 Change
      Owner-User: Full
      User:at1.com/tester10 Delete
      Group:at1.com/aclgrp3 Read
      Owner-Group: Change
      User:at1.com/tester1 Change
      Role:READER Read
      User:at1.com/tester8 mod-hlink
      User:at1.com/tester6 mod-label
      User:at1.com/tester3 mod-props
    policy ACL:
      Role:admin Full
      User:at1.com/tester0 Full
      Group:at1.com/aclgrp15 Read
      User:at1.com/tester6 lock,Change
      Group:at1.com/aclgrp6 Change
      User:at1.com/tester5 chmaster
      User:at1.com/tester7 read-info
    rolemap ACL:
      User:at1.com/tester20 Read
      Role:READER Read
      Group:at1.com/aclgrp6 chmaster
      Group:at1.com/aclgrp5 Delete
      User:at1.com/tester0 Full
      Owner-Group: Read

Example of same policy in non-preserving replica:

policy "pol-01"
 2012-11-20T14:09:53-05:00 by Tester Tester (tester0.user@qvml087)
  master replica: original@/tmp/vob-03
  owner: tester17
  group: user
  contents:
    vob ACL:
      User:at1.com/tester17 Full
      Group:at1.com/user Read
    element ACL:
      Owner-User: Full
      Owner-Group: Change
      Role:READER Read
      User:at1.com/tester17 mod-label,Delete,AclWrite,Change
      Group:at1.com/user Change
    policy ACL:
      Role:admin Full
      User:at1.com/tester17 Full
      Group:at1.com/user Change
    rolemap ACL:
      Role:READER Read
      Owner-Group: Read
      User:at1.com/tester17 Full
      Group:at1.com/user chmaster,Delete

Example of rolemap in mastering replica:

rolemap "role-01"
 2012-11-20T14:10:27-05:00 by Tester Tester (tester0.user@qvml087)
  master replica: original@/tmp/vob-03
  owner: tester0
  group: user
  implements policy: pol-01
  contents:
    Role:READER
      User:at1.com/tester1
      User:at1.com/tester5
      Group:at1.com/aclgrp10
      User:at1.com/tester4
      User:at1.com/tester3
    Role:admin
      User:at1.com/tester0
      Group:at1.com/aclgrp3
      User:at1.com/tester6
      User:at1.com/tester7

Example of same rolemap in non-preserving replica:

rolemap "role-01"
 2012-11-20T14:10:27-05:00 by Tester Tester (tester0.user@qvml087)
  master replica: original@/tmp/vob-03
  owner: tester17
  group: user
  implements policy: pol-01
  contents:
    Role:READER
      User:at1.com/tester17
      Group:at1.com/user
    Role:admin
      User:at1.com/tester17
      Group:at1.com/user

Rolemap and policy oplog behavior

In a non-preserving replica, creating or updating a policy or rolemap will generate oplogs. However, only the creation oplogs will be replayed by other replicas—modification oplogs will not be replayed. (It is not safe to replay modifications because they are possible on non-mastered objects.) When any other replica imports a policy or rolemap creation oplog generated at a non-preserving replica, it will substitute the credentials of the account running multitool syncreplica -import for User and Group entries.

Replay of changes to object-rolemaps bindings

Non-preserving replicas' changes of object-rolemap bindings with protect -chrolemap are not replayed at other replicas. This enables the non-preserving replica to move objects to other rolemaps' protection independently of other replicas. The oplogs are generated although they are ignored in routine operation (however, they are useful for some recovery operations).

Protection of new objects

For controlled objects, new object creation oplogs include a reference to the controlling rolemap assigned during creation. For elements, the oplog also identifies the parent directory element and its rolemap.

During replay at a non-preserving replica, except for elements, the new object is bound to the same controlling rolemap as shown in the oplog.

Element creation oplogs are handled specially. Because the rolemaps used at the non-preserving replica are likely to be different than those at other replicas, the rolemap bound to a new element is not the rolemap assigned at the generating replica. Instead, DevOps Code ClearCase® binds the new element to the new element's parent directory element's rolemap, as known to the importing replica. If the generating replica had different rolemaps bound to the parent directory element and to the new element, a warning message is added to the event record on the import event. This message is stored in the event history, you can see it with cleartool lshistory element

For example, replica A uses rolemap A1 to protect the parent directory element (PDE). Non-preserving replica B uses rolemap B1 to protect that same element. Replica A makes a new element and catalogs it into the PDE, binding the new element to rolemap A1. During replay at replica B, the new element is instead bound to rolemap B1, the rolemap that controls the PDE at replica B.

Example #2: As before, with the addition of rolemap A2. During mkelem, replica A binds the new element to A2 instead of A1 (e.g. mkelem -rolemap), because the new element is supposed to be protected differently than its parent. During replay at replica B, the new element is still bound to B1 (the rolemap controlling the PDE), because A2 is not suitable for use in replica B and ClearCase does not know how to find a better rolemap to substitute for A2.