Permissions-preserving replicas

Permissions-preserving replicas maintain the same permissions on elements, and changes to permissions are synchronized among the other replicas in the family that preserve permissions, including those that preserve both identities and permissions.

Read, write, and execute permissions for user, group, and other are preserved. The SID (Windows®), set-UID bit, set-GID bit, and sticky bit (Linux® and the UNIX® system) are not preserved.

Attention: If you need to restrict read or execute permissions to certain subgroups, do not use permissions-preserving replicas. It is possible for a malicious user at one site to change the permissions on an element in order to grant read access to a user at another site who is not the element owner or in the element’s group. If you choose to use permissions-preserving replicas, you may want to define a trigger that informs you when a cleartool protect command is run. Also, when you run mkreplica –import and create a permissions-preserving replica, make sure that your primary group is appropriate.

In order for you to change a replica to be permissions-preserving or to create a new permissions-preserving replica, the VOB family feature level of the replica must be at least 4. Also, the cleartool protect command fails if you use the –chmod option, specify an object in a permissions-preserving replica, and your client host is running a version of DevOps Code ClearCase® associated with feature level 3 or lower.

Permissions-preserving replicas ignore changes to identities made at other replicas and maintain their own identities information for elements. For permissions-preserving replicas:
  • The user who enters the mkreplica –importcommand becomes the owner of the new VOB and of all elements in it. When you import an update packet containing oplogs for new elements, the VOB owner becomes the owner of the new elements.
  • The primary group of the user who enters the mkreplica –import command becomes the VOB’s primary group and the group for all elements. When you import an update packet containing oplogs for new elements, the VOB’s primary group is the group for the new elements.
  • Changes to identities made at this non-identities-preserving replica are not recorded in oplogs, and therefore are not propagated to other replicas. Identities changes made at replicas that preserve identities are ignored at permissions-preserving replicas.

To create a replica that preserves permissions, you should run mkreplica –export at an identities- and permissions-preserving replica or a permissions-preserving replica.