Preventive Service Planning
This technote provides you with information about IBM® Rational® ClearCase® and discusses the problems that arise when the ClearCase Administrators group owns the VOB or VOB data (elements, metadata) on Microsoft® Windows®.
When a VOB or objects contained within a VOB (elements and metadata) are owned by the ClearCase Administrators group, this will most certainly result in permissions errors whenever an operation is performed against that object by a non-Admin user.
Since the administrators group by default has access to all ClearCase objects, it is not necessary to explicitly add that group and should be avoided.
If as an Administrator you need to ensure that you authenticate as a ClearCase administrator, you can set the CLEARCASE_GROUPS variable to include the ClearCase Administrators group and set the CLEARCASE_PRIMARY_GROUP to the ClearCase users group.
- Review technote 1124574 for more information about the CLEARCASE_GROUPS variable.
- Review technote 1135509 for more information about the CLEARCASE_PRIMARY_GROUP variable.
Do not add all users to the privileged group in an attempt to provide them access to the misprotected objects as this will pose a security risk since all those users would then be considered ClearCase admins. Instead you should reprotect the objects to the proper group (preferably a ClearCase users group) which the users are all a member of and which is a group that owns the VOB and all VOB objects.
Review the ClearCase Command Reference Guide on the topic of permissions (cleartool man permissions) for more information.
HOW CLEARCASE OBJECTS GET SET TO THE CLEARCASE ADMIN GROUP
So, how does the administrators group get mistakenly assigned to a VOB or VOB object (or even a view)?
- This can occur in a case where a user is a member of the administrators group and their Windows domain account has the users primary group set to that group.
- This can also occur if that user's sets their primary group (CLEARCASE_PRIMARY_GROUP environment variable) to the ClearCase administrators group.
ClearCase objects subsequently created by the above users will by default be owned by that primary group.
From either of the command outputs below we can see that the users primary group is set to the ClearCase Administrators group "MYDOMAIN\CLEARCASE"
C:\Documents and Settings\joe>set
Login name: MYDOMAIN\joe
Primary group: MYDOMAIN\clearcase (NT:S-1-5-21-141845252-1443263951-584457872-1022)
NT AUTHORITY\INTERACTIVE (NT:S-1-5-4)
NT AUTHORITY\Authenticated Users (NT:S-1-5-11)
You have ClearCase administrative privileges.
- Elements & Metadata:
In the case of VOB objects such as elements and metadata which are owned by only one group, setting that group to the administrators group will block any normal user from performing certain ClearCase operations against that object. This will occur through a number of ClearCase operations that validate the group to determine access.
The following element is owned by the ClearCase administrators group:
M:\def\new-vob>cleartool describe -l ccgroup.txt
created 2007-07-09T16:18:04-04 by Joe Mac (joe.clearcase@myhost)
User : MYDOMAIN\joe : r--
Group: MYDOMAIN\clearcase : r--
Other: : r--
element type: text_file
predecessor version: \main\0
The following error will be reported when trying to checkout the above element while logged in as a user who is not a ClearCase administrator and doesn't own the element:
cleartool checkout -nc ccgroup.txt
cleartool: Error: No permission to perform operation "checkout".
cleartool: Error: Must be one of: member of element group, element owner, VOB owner, member of ClearCase group
cleartool: Error: Unable to check out "ccgroup.txt".
Review the Restrictions information in the ClearCase Command Reference Guide under the topic of checkout (cleartool man checkout) for more information.
- VOB object:
The following is the output from a describe of a VOB created by the above referenced user where this VOB is now owned by the ClearCase Administrators group. Any user who is not a member of the ClearCase Administrators group will get permissions errors trying to add ClearCase data to this VOB.
C:\Documents and Settings\joe>cleartool describe -l vob:\new-vob
created 2007-07-06T18:46:48-04 by Joe Mac (joe.clearcase@myhost)
VOB family feature level: 5
VOB storage host:pathname "myhost:D:\clearcase_storage\vobs\new-vob.vbs"
VOB storage global pathname "D:\clearcase_storage\vobs\new-vob.vbs"
database schema version: 54
modification by remote privileged user: allowed
FeatureLevel = 5
Trying to add the ClearCase administrators group to the VOB's group list is not allowed and will report the following error:
C:\Documents and Settings\joe>cleartool protectvob -add_group clearcase \\myhost\clearcase_storage\vobs\june2007.vbs
This command affects the protection on your versioned object base.
While this command is running, access to the VOB will be limited.
Pool "sdft" appears to be protected correctly.
Pool "ddft" appears to be protected correctly.
Pool "cdft" appears to be protected correctly.
Protect versioned object base "\\myhost\clearcase_storage\vobs\june2007.vbs"? [no] y
Do you wish to protect the pools that appear not to need protection? [no] y
cleartool: Error: Trouble protecting versioned object base "\\myhost\clearcase_storage\vobs\june2007.vbs".
The following is the output of a cleartool lsview command which displays the view properties. Since this view is owned by the administrators group, non-privileged users will be unable to perform a checkout operation in that view because they (defaulting to the "Other" credentials) don't have write permissions to the view.
M:\def\new-vob>cleartool lsview -properties new-view
* new-view \\myhost\clearcase_storage\views\new-view.vws
Created 2007-07-06T18:49:20-04 by MYDOMAIN\joe.MYDOMAIN\clearcase@myhost
Last modified 2007-07-06T18:49:20-04 by
Last accessed 2007-07-06T18:49:20-04 by MYDOMAIN\joe.MYDOMAIN\clearcase@myhost
Owner: MYDOMAIN\joe : rwx (all)
Group: MYDOMAIN\clearcase : rwx (all)
Other: : r-x (read)
The ClearCase administrators group maps over to UNIX as nobody (as of ClearCase 4.1) by design to avoid security issues, thus, setting a users primary group to the administrators group will always authenticate over to UNIX as group nobody causing permissions errors.
Review the ClearCase Command Reference Guide on the topic of credmap (cleartool man credmap) for more information.
Objects that are owned by the ClearCase Administrators group may cause import or export errors like the following.
multitool: Error: Unable to create a container in vob "\idunn", because group "SERVER2\clearcase" not in vob's group list.
HOW TO FIX THE PROBLEM
- For a VOB:
Run a cleartool protectvob command to change the VOBs group.
Review the ClearCase Command Reference Guide on the topic of protectvob (cleartool man protectvob) for more information.
- For VOB objects (elements and metadata):
Refer to technotes 1146535 and 1146517 for instructions for reprotecting the data.
Note: The vob_sidwalk cannot be used to change the group on VOB objects that are incorrectly set to the ClearCase Administrators group.
- For a View:
The group of a view on Windows cannot be changed. Views must be recreated.
- Hardcopy can be ordered from the IBM Publications Center.
- On-line documentation can be found:
About the ClearCase Information Center
Note: The on-line ClearCase version 7.x documentation can be found in the IBM Publication Center and has been organized for you in technote 1239261.
Note: The 2003.06.00 ClearCase manuals can be found on-line in the Legacy Rational product documentation section for the ClearCase Family.
Internal Use Only
A Japanese technote 1459547 exists, which is a translation of this English document.
IMPORTANT: If this technote is modified with significant changes, the changes need to also be applied to the Japanese through an update request. Spelling and grammatical changes are likely not significant
to the translated content. If multiple translated versions exist, this process must be repeated for them as well.
There may be situations where shared views that are owned by the admin group will prevent access. Once the non owner tries to access view they receive unable to access errors.
16 June 2018