IBM Support

Problems that occur if the ClearCase Administrator group owns the VOB or VOB objects

Preventive Service Planning


Abstract

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®.

Content










INTRODUCTION

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.



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)?


ClearCase objects subsequently created by the above users will by default be owned by that primary group.

EXAMPLE:

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
   ...
   CLEARCASE_PRIMARY_GROUP=MYDOMAIN\
CLEARCASE
   ...<cropped>...

C:\Program Files\Rational\ClearCase\etc\utils>creds
Login name:    MYDOMAIN\joe
USID:          NT:S-1-5-21-141845252-1443263951-584457872-1606
Primary group: MYDOMAIN\
clearcase  (NT:S-1-5-21-141845252-1443263951-584457872-1022)
Groups: (8)
   MYDOMAIN\user (NT:S-1-5-21-141845252-1443263951-584457872-1023)
   Everyone (NT:S-1-1-0)
   BUILTIN\Administrators (NT:S-1-5-32-544)
   BUILTIN\Users (NT:S-1-5-32-545)
   NT AUTHORITY\INTERACTIVE (NT:S-1-5-4)
   NT AUTHORITY\Authenticated Users (NT:S-1-5-11)
   LOCAL (NT:S-1-2-0)
   MYDOMAIN\Domain Users
NT:S-1-5-21-141845252-1443263951-584457872-513)

You have ClearCase administrative privileges.


IMPACT


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.

Example:

The following element is owned by the ClearCase administrators group:

M:\def\new-vob>cleartool describe -l ccgroup.txt
version "ccgroup.txt@@\main\1"
 created 2007-07-09T16:18:04-04 by Joe Mac (joe.clearcase@myhost)
 Element Protection:
   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
versioned object base "\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
  VOB ownership:
    owner MYDOMAIN\joe
    group MYDOMAIN\ clearcase
  Attributes:
    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".

  • View:

    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
    MYDOMAIN\joe.MYDOMAIN\clearcase@myhost
    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)

  • Interop:

    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.

  • MultiSite:

    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


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.


Documentation


Related information

About ClearCase privileged users on Windows
About the CLEARCASE_PRIMARY_GROUP variable
About the creds utility
About ClearCase permissions on Windows
About changing the ownership of a VOB and it's objects
Change ownership of all objects in a VOB
Summary of protection commands and utilities used with
Understanding NOBODY in the credmap output
A Japanese translation is available

Document information

More support for: Rational ClearCase
VOB

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 #: 1264867

Modified date: 03 October 2007


Translate this page: