3.1 Fundamentals of ClearCase Access Control

ClearCase implements access controls that determine which users can create, read, write, execute, and delete data in ClearCase. Access control depends on the interaction of users and the groups they belong to, ClearCase objects, and user processes or application programs that access ClearCase data on behalf of the users.

Users and Groups

ClearCase does not have its own implementation of user and group accounts. Instead, it relies on the operating system to authenticate users at login time and to provide the details of user identity and group membership that determine a user's rights to execute various ClearCase operations. Both UNIX and Windows provide networkwide databases of user and group names that are well suited to the needs of a distributed application like ClearCase. On UNIX, this database is part of the Network Information System (NIS, NIS+). On Windows, it is part of the Active Directory or Windows NT Domain system.

On both operating systems, a user logs on with a unique user name, which ClearCase uses as the user's identification or user ID. A user ID can be a member of one or more groups, one of which is distinguished as the user's primary group. On UNIX, the primary group is part of the user's entry in the NIS passwd database. On Windows, a primary group can be specified when the user's domain account is created, although each user should also set the user environment variable CLEARCASE_PRIMARY_GROUP to the name of that group (see Setting the ClearCase Primary Group). ClearCase considers both the user ID and primary group when determining a user's access rights to ClearCase objects.

In this document, the term community refers to a set of users and computers that access a common ClearCase LT server. A typical ClearCase LT community includes two classes of user:

• Privileged users have rights to create, modify, and delete all artifacts under ClearCase control. Access to privileged user accounts should be restricted to a few ClearCase administrators.

• Ordinary users have rights to modify VOBs and views that they create, or that have been created by a member of their primary group. We recommend that all ClearCase users in a community be members of the same primary group. This can be a group that already exists, or one that you create expressly for use by the ClearCase community.

NOTE: ClearCase on Windows has a few special requirements for creation of users and groups in Windows domains. See Domain User and Group Accounts.

Privileged Users and Groups

Some users and groups have special importance for ClearCase access control. For example, each ClearCase object has an owner, usually the creator of the object, who often has special access rights to the object. If the object is a container object, such as a VOB that contains elements, the ownership of the container object may in part determine who has access to the objects it contains.

ClearCase has a general notion of the privileged user, a term used throughout this book to describe a user who is authorized to perform certain critical operations on the ClearCase LT server. (There is no privileged user on the ClearCase LT client.)

• On a ClearCase LT server running UNIX, the privileged user is the root user logged in to the local host. Several limitations apply to the privileges of a root user logged in to a remote host. These limitations are described in detail in Restricted Privileges for Remote root.

• On a ClearCase LT server running Windows, the privileged user is any member of the local Administrators group on the ClearCase LT server host.

On either UNIX or Windows, the privileged user has the right to create, delete, and modify VOBs and the objects that VOBs contain. Access to the privileged user account should be restricted to ClearCase administrators.

Restricted Privileges for Remote root

Although many ClearCase operations on UNIX hosts treat a remote root user (one who is not logged in to the local host) as a privileged user, there are several exceptions to this rule.

• When a user logged in as root on a UNIX host attempts to access a view on another UNIX host, the user's identity is interpreted as nobody.nobody (unidentified user, unidentified group). This interpretation is typical of NFS implementations on UNIX, and provides a level of security comparable to that provided by NFS. ClearCase does not support any mount option that controls how requests for access by a remote root user are treated, so it will not allow view access by a remote root user unless the view has been created to be usable by nobody.nobody.

• Operations that change the user or group ownership of an object in a VOB (cleartool protect -chown or -chgrp) will not succeed if they are requested by a remote root user.

User Processes

Any user request to read or write ClearCase data causes a user process (such as a ClearCase GUI or command-line program, or a non-ClearCase program such as a text editor that accesses ClearCase data in a dynamic view) running with that user's identity to request access to the data.

A user process has several properties that ClearCase evaluates to determine whether to grant the process access to the requested data:

• User. This is the user who starts the process.

• Primary group. This is the primary group of the user who starts the process.

• Supplemental group list. These are any other groups of which the user who starts the process is a member.

This chapter refers to a process's primary group and other groups together as the process's groups.

ClearCase Objects

The following ClearCase objects are subject to access control:

• VOBs

• 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

• Views

NOTE: The ClearCase scheduler maintains its own access control mechanism. See Managing the Scheduler Access Control List.

Each of these objects has one or more of these properties, which are important for access control:

• Owner. The owner is a user. The initial owner is the user identity of the process that creates the object. For some objects, the initial owner can be changed.

• Group. The initial group is the primary group of the process that creates the object. For some objects, the initial group can be changed.

• Protection mode. Some objects also have a protection mode. The mode consists of three sets of permissions, one for each of these user categories:

• The object's owner

• Any member of the object's group

• All other users

Each set of permissions consists of three Boolean values for a user in its category. Each value determines whether the user has one of these permissions to act on the object:

• Read permission, or permission to view the object's data.

• Write permission, or permission to modify the object's data. For an object that contains other objects, such as a VOB or a directory, write permission generally means permission to create or delete objects within the containing object.

• Execute permission. For a file object, execute permission is permission to run the file as an executable program. For a directory object, execute permission is permission to search the directory.

The protection mode for a ClearCase object is summarized in Table 1. Information about an object's protection mode usually takes the form of a single-character abbreviation of each Boolean value in the protection mode; these abbreviations appear in Table 1.

Table 1 Protection Mode for a ClearCase Object

User Category	Read Permission?	Write Permission?	Execute Permission?
Object's Owner	Yes (r) or No (-)	Yes (w) or No (-)	Yes (x) or No (-)
Member of Object's Group	Yes (r) or No (-)	Yes (w) or No (-)	Yes (x) or No (-)
Other	Yes (r) or No (-)	Yes (w) or No (-)	Yes (x) or No (-)

For example, suppose you are working in a view and want to see the protection mode for the directory element myproj in the projects VOB. Suppose the owner and group of myproj have read, write, and execute permission, but other users have only read and execute permissions. The cleartool describe command displays the mode, along with the elements's owner (sue) and group (clearusers), as follows:

cleartool describe myproj
...
Element Protection:
User : sue rwx
Group: clearusers rwx
Other: r-x
...

In addition to these single-character abbreviations, ClearCase sometimes uses integers to display object permissions in a compact form. For each user category (owner, group, and others), a single digit from 0 through 7 represents the permissions for that category, as described in Table 2.

A sequence of three digits in a row expresses the protection mode for an object, in this order: owner's permissions, group's permissions, others' permissions. For example, the protection mode 750 for an object means that it has these permissions:

Access to ClearCase Data

Whether a process has access to a ClearCase object depends on these factors:

• The user and groups of the process

• The owner and group of the object

• The protection mode of the object, if any

When a process seeks access to a protected object, the following algorithm usually determines whether access is granted:

1. Does the process have the user ID of the owner of the object?

• Yes: grant or deny access according to the object's protection mode for the Owner category.

• No: go to Step #2.

2. Does the process have the group ID of the group of the object

• Yes: grant or deny access according to the object's protection mode for the Group category.

• No: go to Step #3.

3. Grant or deny access according to the object's protection mode for the Other category.

If an object has no protection mode, ClearCase determines whether to grant access by using rules that depend on the type of object. See the descriptions in Access Control for VOBs and VOB Objects and Access Control for Views and View Objects.