About ClearCase permissions on Windows

Technote (FAQ)


Question

What are the recommended permissions and access requirements for IBM Rational ClearCase users and groups in a Microsoft Windows environment?

Cause

The Microsoft Windows New Technology File System (NTFS) protects objects using security descriptors. File Access Table (FAT) file systems do not use security descriptors. Therefore, IBM Rational recommends using the NTFS file system for maximum security of data. This technote will address ClearCase permissions as they pertain to NTFS.

Answer

There are required Windows permissions for various directories (VOBs, views, shares, and install) to enable ClearCase to function properly and without error. Some ClearCase operations will generate access and permission denied errors if certain directories or shares have the wrong permissions.

Note: ClearCase does not have a built-in authentication mechanism. ClearCase relies on the Microsoft Windows permissions model to enforce security using Microsoft Windows groups, user accounts, file system and share permissions to enforce security models.







Important Advisory

This information is intended for use by the ClearCase Administrator (or systems administrator), who is responsible for configuring the ClearCase environment.

Note: This document provides specifications for ClearCase use, but general security and access controls for any network and its applications should be evaluated by a certified system and/or network administrator who can verify the appropriate configuration for your production requirements.

To setup protections for ClearCase, we recommend that you first read and understand the details covered in the IBM Rational ClearCase Administrator's Guide . If you do not have a hard copy, the document is available in soft copy, cc_admin.pdf, on any host with ClearCase installed, and is located by default in C:\Program Files\Rational\ClearCase\doc\books .

The goal of this technote is to supplement the IBM Rational ClearCase Administrator's Guide by providing considerations and guidelines to assist with managing the protections in a ClearCase environment. Due to the broad variances of protections that can be implemented to address the security needs in different environments, this technote cannot provide specifications that will be true for all cases.


Non-ClearCase vs ClearCase Protections

It is important to understand that protections for non-ClearCase objects, such as shares used as storage locations or the install directory, are managed using operating system commands, while protections of ClearCase objects (VOBs, views, elements, versions, and other VOB objects) are managed using ClearCase utilities and commands.

In short, non-ClearCase objects are directories (or folders) that are created using operating system functions, where as ClearCase objects are created using ClearCase functions or have been added to source control.

For information on the ClearCase utilities and commands used for changing VOB and view storage protections, see the IBM Rational ClearCase Administrator's Guide and the IBM Rational ClearCase Command Reference manual.

ClearCase Administrative Access

Privileged users in ClearCase have rights to create, modify, and delete any ClearCase object. Access to these permissions should be restricted to ClearCase Administrators and the ClearCase Process Account (Atria Location Broker Service - ALBD). Access is controlled by membership in the ClearCase Administrators group.

This group which is designated during the setup and installation of ClearCase is referred to as the ClearCase privileged group. By default, this group is called clearcase. Some defining characteristics of the ClearCase (or privileged) group are:
  • The account under which whose identity Atria Location Broker Daemon (ALBD) runs has to be a member of this group, such as clearcase_albd.
  • This group has Full Control of the view and VOB storage directories.
  • Members of this group are considered ClearCase Administrators.

Note: The ClearCase privileged group must never be used as the primary group on a VOB or set as a primary group for ClearCase access.


Windows Permissions for ClearCase

Windows permissions are composed of three elements:
  • Security Descriptors
  • File Permissions
  • Directory Permissions
Security Descriptors

Security descriptors contain information about ownership of objects: who owns the object, who can access the object, and the types of access allowed for the object. A discretionary access control list (DACL) is a component of a security descriptor which is viewable and modifiable by users with read access to the object. Note that the terms DACL and access control list (ACL) are used interchangeably.

VOB and view storage directories (ending with .vbs and .vws ) use identity.sd and groups.sd files that describe ownership, regardless of the file system on which they reside. The contents of these files can be viewed using the lsacl -f command.

Additional information regarding the VOB and view access control list can be found in the Troubleshooting Section in the IBM Rational ClearCase Administrator's Guide

Note: If permissions on the VOB or view storage directories (.vbs or .vws) are manually modified from the operating system level, ClearCase may not recognize the access control list (ACL) format of those permissions and you will need to run fix_prot on the VOB or view storage directory. Review technote 1142606 for directions on running fix_prot. Also, see the VOB and View Administration sections in the IBM Rational ClearCase Administrator's Guide.

  • ClearCase Server Storage Locations or Shares:

    These permissions are controlled by the operating system and not by ClearCase. However, these settings can impact ClearCase operations.

    Whether you are using the mkstgloc command to create your VOB/view storage location or you simply share out a directory on the server for storing VOBs and views (for example viewstore or vobstore), the Windows share permissions on the folder must be as follows:

    a. ClearCase Administrative Group (clearcase) - Full Control (both VOBs and views)

    b. ClearCase Users Groups - Full Control on the share (views only)

    c. ClearCase Users Groups - Change on the share (for VOBs) for the following groups:

  • VOB's Primary Group
  • Additional groups on VOBs group list

Note: See technote 1147041 for more details on server storage locations.

  • ClearCase Home directory and all subdirectories

    a. ClearCase Administrative group (clearcase) - Full Control

    b. ClearCase Home = C:\Program Files\IBM\RationalSDLC\ClearCase

    For ClearCase versions prior to 7.1.0.0 the default path is C:\Program Files\Rational\ClearCase



Recommendations

Due to the fact that share and NTFS permissions combine for the most restrictive when accessed over the network, the easiest way to control access to the VOB and view storage directories is to use share access controls, and leave the underlying NTFS directories as "Everyone: Full Control".

For more information regarding share and NTFS permissions, refer to the following:

http://www.microsoft.com/technet/technetmag/issues/2006/01/HowITWorksNTFS/?related=/technet/technetmag/issues/2006/01/HowITWorksNTFS

http://technet2.microsoft.com/windowsserver/en/library/d043701a-5a2e-4001-b659-0c23c90f76f61033.mspx?mfr=true

http://technet2.microsoft.com/windowsserver/en/library/87b011ec-b1b4-4baf-8ab0-53147b22a4201033.mspx?mfr=true

http://support.microsoft.com/kb/301195

Since User Access Rights can be modified on the view or VOB server to limit who has the right to logon locally, this would limit the impact of using “Everyone: Full Control” on the NTFS file system. This permission would only apply to users who have interactive logon rights. For more information regarding interactive logons and user rights, please refer to: http://support.microsoft.com/kb/823659 Changing this type of access should not impact users who access shares over the network.


However, if the security restrictions in your environment do not allow the use of “Everyone: Full Control”, you will have to align your share and NTFS permissions to get the correct results. It is up to your administrator to determine what Windows permissions are appropriate for your environment based on your security requirements. As stated above, IBM Rational can only specify generic guidelines, which should be reviewed by a certified system and/or network administrator as it is not possible to address specific permissions for every environment.

The following permissions are the minimum required for ClearCase to function correctly. If Windows security (disk, registry, policies, etc) has been set in a manner that is too restrictive for ClearCase to function properly, additional modifications may be required for your environment.

The share permission levels and the ClearCase functions they permit are:

  • Full Control -
  • This is the minimum level of permission needed to create VOBs and Views.
  • This level is needed because the cleartool process creates and protects the VOB/View database. Changing the ACL on a file in a share requires "Full Control" access through that share.

  • Change -
  • This is the minimum share permission level (read and write) to use, but not create, a ClearCase VOB or view.
  • This is needed because a number of ClearCase commands will be directly modifying files in VOB storage pools, and file system commands may be indirectly modifying files in a view's pools.

The minimum NTFS permissions required to use, but not create, a VOB or a view are:
  • Full Control for the ClearCase Administrators Group on both the VOB and view shared folders
  • Read, List Folder Contents, Read & Execute, Write for the ClearCase User Groups on the view shared folder.
  • Read, List Folder Contents, Read & Execute for the ClearCase User Groups on the VOB shared folder.

The minimum NTFS permissions required to create a VOB or a view are:
  • Full Control for the ClearCase Administrators Group on both the VOB and view shared folders.
  • Full Control for a user (if you want a specific user to be able to create a VOB but do not want them to be added to the ClearCase Administrators Group) on the VOB shared folder. This user must be a member of VOB's primary group.
  • Full Control for the ClearCase User Groups to allow view creation on the view shared folder


Permission examples when accessing a shared folder:
  • An example of how permissions combine:
  • ClearCase Administrators group has Full Control on the share
  • ClearCase Users group has Change on the share to use VOBs or views
  • Everyone has Full Control on NTFS

The effective permissions when accessing the shared folder over the network are:
  • ClearCase Administrators group has Full Control
  • ClearCase Users group has Change
  • An example of combined permissions that would cause a problem:
  • ClearCase Administrators group has Full Control on the share and NTFS
  • ClearCase Users Group has Change on the share and Full Control on NTFS
  • Everyone has Read on NTFS

The effective permissions when accessing the shared folder over the network are:
  • ClearCase Administrators group has Read
  • ClearCase Users group has Read

Note: If the Everyone group was removed from the NTFS permissions, the effective permissions accessing the share over the network in Example 2 would be the same as Example 1.

Note: Refer to the Preserving NTFS ACLs when copying a VOB or view storage directory section of the ClearCase Administrators Guide for information about special considerations regarding the NETWORK group ACLs on a NAS.

Related information

About the creds utility
About ClearCase Primary Group EV
About changing the ownership of a VOB
Troubleshooting ALBD startup failures on Windows
About Additional Groups in the VOBs group list
About ClearCase privileged users on Windows
Could not set ACL when changing the reqmaster perms
A Japanese translation is available

Rate this page:

(0 users)Average rating

Add comments

Document information


More support for:

Rational ClearCase
Permissions

Software version:

7.0, 7.0.1, 7.1, 7.1.1, 7.1.2, 8.0, 8.0.1

Operating system(s):

Windows

Reference #:

1143292

Modified date:

2014-04-16

Translate my page

Machine Translation

Content navigation