|
|
VOBs are the principal repositories for ClearCase data. Both VOBs themselves and objects within VOBs participate in access control. These objects include the following:
Elements and versions
Types and instances of types, such as labels, branches, and attributes
Unified Change Management objects, such as projects, folders, activities, and streams
VOB storage pools
These VOB properties are important for access control:
Owner. The initial owner is the user of the process that creates the VOB.
Group. The initial group is the primary group of the process that creates the VOB.
Supplemental group list. The initial supplemental group list is empty for a Windows VOB. For a UNIX VOB, it contains the group list of the VOB owner.
A VOB has no protection mode. This chapter refers to a VOB's primary group and other groups as the VOB's groups.
You can use the cleartool describe command to display the owner, group, and supplemental group list for a VOB.
After a VOB is created, a privileged user can use the cleartool protectvob command to change the VOB's owner, group, or supplemental group list.
NOTE: You cannot use protectvob to add the ClearCase administrators group to a VOB's supplemental group list. Members of this group already have full access rights to all VOB objects.
Only the VOB owner or a privileged user can delete a VOB.
You cannot read a VOB directly. Read operations on a VOB are read operations on objects within the VOB. See Access Control for Elements and Access Control for Other VOB Objects.
You cannot write a VOB directly. Write operations on a VOB include creating and deleting objects within the VOB. See Access Control for Elements and Access Control for Other VOB Objects.
You cannot execute a VOB directly. Execute operations on a VOB are execute operations on objects within the VOB. See Access Control for Elements and Access Control for Other VOB Objects.
An element has these properties that are important for access control:
Owner. The initial owner is the user ID of the process that creates the element.
Group. The initial group is determined differently on UNIX and Windows hosts.
On UNIX, it is the primary group ID of the process that creates the element.
On Windows, it is the primary group ID of the process that creates the element if that group is on the VOB's group list. Otherwise, it can be any group that appears on the group list of process that creates the element and also on the group list of the VOB.
The group of an element must be one of the VOB's groups.
Protection mode. The initial protection mode for a file element is determined differently on UNIX and Windows hosts.
On UNIX, if you create the element from an existing file, the element has the same protection mode as the file, except that no user category has write permission. If you create a file element any other way, the element has only read permission for all user categories. If your umask is 0, a directory element initially has read, write, and execute permission for all user categories. Otherwise, the initial read, write and execute permissions are determined by the value of your umask.
On Windows, a file element initially has only read permission for all user categories. You must explicitly add execute permission for an element by using the cleartool chmod command. A directory element initially has read, write, and execute permission for all user categories.
An element's owner, group, and protection mode are the same for all versions of the element.
You can use the cleartool describe command or, on Windows, the Properties of Element dialog box to display the owner, group, and protection mode for an element.
After an element is created, the element owner, the VOB owner, or the privileged user can use the cleartool protect command to change the element's owner, group, or protection mode.
When you create a VOB, ClearCase creates an initial element, the VOB root directory. This element is the top-level container for other elements in the VOB. Its initial owner is the owner of the VOB, and its initial group is the group of the VOB.
Only a process whose primary group is one of the VOB's groups can create any other element. That process must also have permission to check out a version of the directory element that contains the new element. See Permission to Write Elements.
Only the element owner, the VOB owner, or the privileged user can delete an element. Deleting an element, using the cleartool rmelem command, is not the same as removing the element from a directory version. See Permission to Write Elements.
The creator of a version, the element owner, the VOB owner, or the privileged user can delete the version.
An algorithm that considers the process's user and group and the element's owner, group, and protection mode determines whether to grant read permission for an element. See Access to ClearCase Data.
A process cannot write elements directly. You modify an element by checking out a version of it and checking in a new version.
The element's protection mode is not considered when determining whether a process can check out or check in a version. A process can check out a version if any of these conditions exist:
The process has the user identity of the element's owner.
Any of the process's group identities is the same as the element's group.
The process has the user identity of the VOB owner.
The process has the user identity of the privileged user.
A process can check in a version if any of these conditions exist:
The process has the user identity of the user who checked out the element.
The process has the user identity of the element's owner.
The process has the user identity of the VOB owner.
The process has the user identity of the privileged user.
When a directory element is checked out, you can modify the directory by creating elements or by removing elements from it. Removing an element's name from a directory, using the cleartool rmname command, is not the same as deleting the element itself. See Permission to Delete Elements.
An algorithm that considers the process's user and group and the element's owner, group, and protection mode determines whether to grant execute permission for an element. See Access to ClearCase Data. In addition, two special cases can restrict permission to execute an element:
On Windows, a file element does not have execute permission until you add it by using the cleartool chmod command. For example:
cleartool chmod +x command.exe
If you add an executable program to source control, you will not be able to execute it until you take this step.
On UNIX, a VOB mounted with the nosuid mount option will not allow setuid executables to run.
In addition to elements and versions, a VOB contains other kinds of objects that are subject to access control:
Metadata types, such as label types, branch types, and attribute types
Unified Change Management objects, such as projects, activities, folders, and streams
Storage pools
In general, each of these objects has two properties that are important for access control:
Owner. The initial owner is the user of the process that creates the object.
Group. The initial group is the primary group of the process that creates the object.
You can use the cleartool describe command to display the owner and group of an object. After the object is created, the object's owner, the VOB owner, or the privileged user can use the cleartool protect command to change the object's owner or group. The group of the object must be one of the VOB's groups.
Any user can create a type or a UCM object. Only the VOB owner or the privileged user can create a storage pool.
Instances of types, such as labels, branches, and attributes, are usually associated with element versions. To create an instance of one of these types, one of the following conditions must exist:
The process has the user identity of the element's owner.
Any of the process's group identities is the same as the element's group.
The process has the user identity of the VOB owner.
The process has the user identity of the privileged user.
The owner of the object, the owner of the VOB, or the privileged user can delete a type or UCM object.
Instances of types, such as labels, branches, and attributes, are usually associated with element versions. In general, if you can create an instance of a type, you can also delete the instance. See Permission to Create Other VOB Objects. In addition, the creator of a branch can delete the branch.
Any user can display information about a type, a UCM object, or a storage pool.
Any user can change a UCM object. The owner of the object, the owner of the VOB, or the privileged user can change a type.
The ClearCase permissions scheme is intended for use as a long-lived access-control mechanism. ClearCase also provides for temporary access control, through explicit locks on individual VOB objects. You can use the lock command to restrict or prohibit changes at various levels. At the lowest level, you can lock an individual element, or even an individual branch of an element. At the highest level, you can lock an entire VOB, preventing all modifications to it.
When an object is locked, it cannot be modified by anyone, even the privileged user or the user who created the lock. (But these users have permission to unlock the object.) The lock command accepts an exception list that specifies which users can modify the object despite the lock.
You can lock type objects; this prevents changes to the instances of those types. For example:
You can lock the branch type main to all but a select group of users. This group can then perform integration or release-related cleanup work on the main branches of all elements. All other users can continue to work, but must do so on subbranches, not on the main branch.
Locking a label type prevents anyone from creating or moving that label. Labeling all the element versions used in a particular release, and then locking that label, provides an easy way to re-create the release later.
|
|
Feedback on the documentation in this site? We welcome any comments!
Copyright © 2001 by Rational Software Corporation. All rights reserved. |
