IBM Support

About Additional Groups in the VOB's group list

Technote (FAQ)


Question

How can I add (or remove) additional groups to the IBM® Rational® ClearCase® VOB's groups list, do these groups have the same access rights to the VOB as its primary group, and how many additional groups are permitted on Microsoft® Windows®, UNIX® or Linux®?

Answer

All VOBs have a primary group that is set per the account that is used to create it, and, by default, this is the only group in the VOB's group list.

We recommend that a ClearCase user's group, such as ccase_users or ccusers, be created and maintained in the environment for users that will access the repository. There are no specifications for the naming of the group, it just serves to maintain access control to VOB objects.

Note: On Windows, there is a privileged group (by default, it is named clearcase), which is a group granted special rights for working in the application and with the databases, see technote 1146253 for more details. On UNIX and Linux, the root account serves the equivalent purpose as this group (does on Windows).

The account used to create the VOB should be a member of the ClearCase user's group and it should be set as the primary group. For details on setting this group as the primary group of a user account, refer to technote 1135509.

Note: To determine the primary group of a user account, from a host with Rational ClearCase installed, you can use the creds utility as detailed in technote 1221403.

The following information provides details related to putting more groups in the group list of a VOB.









Overview of cleartool protectvob

You can put an additional group in the VOB's group list using cleartool protectvob -add_group, and remove it using cleartool protectvob -delete_group.

After adding the group, it will now have the same access rights and abilities granted to the VOB's primary (or owning) group. However, this does not mean that the group will have full access to the elements in the VOB. There is a distinction between VOB protections and element protections, which is discussed in this technote.

The cleartool protectvob command changes owner or groups of a VOB. Adding a group to the VOB's group list grants it access to the VOB by changing the operating system level permissions on files and directories stored in the VOB storage area. This does not necessarily grant the additional group permissions for accessing the elements and metadata stored in the VOB database.

Note: The cleartool protect command changes permissions or ownership of a VOB object. Access to the elements and metadata adhere to the permissions set on VOB objects by cleartool protect; this includes the VOB root. The cleartool protect command sets the owner, group, or permissions for one or more elements, shared derived objects, or named VOB objects, which are maintained in the VOB database. Refer to the man page, cleartool man protect, for more details.


Restrictions for running cleartool protectvob

The restrictions for running cleartool protectvob are:


Note: The restrictions and more details on this command are documented in the IBM Rational ClearCase Command Reference, or run cleartool man protectvob.




Adding Groups to a VOB group list

Syntax:
cleartool protectvob –add_group group-name[, ...] vob-stg-pname

Windows

    C:\> cleartool protectvob -add_group added_group2 \\server\ccstg_c\VOBs\test1.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 "\\server\ccstg_c\VOBs\test1.vbs"?  [no] Yes
    Do you wish to protect the pools that appear not to need protection?  [no] Yes
    Protecting "\\server\ccstg_c\VOBs\test1.vbs\db\logs"...
    Protecting "\\server\ccstg_c\VOBs\test1.vbs\db"...
    Protecting "\\server\ccstg_c\VOBs\test1.vbs\admin\vob_space"...
    Protecting "\\server\ccstg_c\VOBs\test1.vbs\admin\do_space"...
    Protecting "\\server\ccstg_c\VOBs\test1.vbs\admin"...
    Protecting "\\server\ccstg_c\VOBs\test1.vbs\s\sdft\19\f"...
    Protecting "\\server\ccstg_c\VOBs\test1.vbs\s\sdft\19"...
    Protecting "\\server\ccstg_c\VOBs\test1.vbs\s\sdft"...
    Protecting "\\server\ccstg_c\VOBs\test1.vbs\d\ddft"...
    Protecting "\\server\ccstg_c\VOBs\test1.vbs\c\cdft"...
    VOB ownership:
    owner SERVER\Administrator
    group SERVER\ccusers
    Additional groups:
    group SERVER\added_group1
    group SERVER\added_group2


UNIX and Linux
    # /usr/atria/bin/cleartool protectvob -add_group group3 /tmp/tommy.vbs
    This command affects the protection on your versioned object base.
    While this command is running, access to the VOB will be limited.
    If you have remote pools, you will have to run this command remotely.
    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 "/net/phosphate/tmp/tommy.vbs"?  [no] yes
    Do you wish to protect the pools that appear not to need protection?  [no] no
    VOB ownership:
    owner atria.com/joeuser
    group atria.com/group1
    Additional groups:
    group atria.com/group2
    group atria.com/group3
    #



Removing Groups from the VOB group list

Windows
    C:\>cleartool protectvob -delete_group added_group3 \\server\ccstg_c\VOBs\test1.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 "\\server\ccstg_c\VOBs\test1.vbs"?  [no] yes
    Do you wish to protect the pools that appear not to need protection?  [no] no
    VOB ownership:
    owner SERVER\Administrator
    group SERVER\ccusers
    Additional groups:
    group SERVER\added_group1

UNIX and Linux
    # /usr/atria/bin/cleartool protectvob -delete_group group3 /tmp/tommy.vbs
    This command affects the protection on your versioned object base.
    While this command is running, access to the VOB will be limited.
    If you have remote pools, you will have to run this command remotely.
    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 "/net/phosphate/tmp/tommy.vbs"?  [no] no
    VOB ownership:
    owner atria.com/joeuser
    group atria.com/group1
    Additional groups:
    group atria.com/group2
    #



Number of Additional Groups is Limited

While many UNIX and Linux operating systems only support having a user belong to a maximum of 16 groups, ClearCase allowed up to 32 additional groups to be added to the VOB group list. Defect
APAR IC47337 has been submitted to address this issue.

Allowing up to thirty-two groups on a VOB's group list can render that VOB unusable on such operating systems.

For example, after adding more than 16 groups with the cleartool protectvob -add_group command on a UNIX/Linux system, the cleartool describe command displays the following error:

cleartool: Error: Problem starting vob_server for vob

cleartool: Error: See albd or vob error logs on host


As a result of adding more groups to the VOB than the maximum on groups per the OS, the VOB is put into a corrupted state. Refer to technote 1126524 for directions on how to troubleshoot and correct this condition.

As of the following updates:



... the number of groups in a VOB's group list is restricted to the number that is permissible by the UNIX and Linux operating system (OS).

This enhancement will cause Rational ClearCase to adhere to the maximum number on groups allowed by the operating system. If you try to add more groups to a VOB than the OS supports, you will get an error:
    VOB <name> already has <x> supplementary groups; only <n> more can be added.

SIDE EFFECT

The maximum number of groups on a Windows' VOB was inadvertently affected by this change and no longer continues to be 32. If you attempt to exceed 16 groups on Windows, the same error as above will occur.

This issue has been logged as APAR PK38808, which has been resolved in the following update(s):

7.0.1
ClearCase

7.0
ClearCase


Related information

About ClearCase permissions on Windows
VOB root permissions impact secondary groups on UNIX
Adding groups to a view's group list on UNIX and Linux
protectvob -add_group fails due to max on groups
Deleted user accounts and ClearCase performance
A Japanese translation is available

Cross reference information
Segment Product Component Platform Version Edition
Software Development Rational ClearCase Permissions

Document information

More support for: Rational ClearCase
Permissions

Software version: 7.0, 7.0.1, 7.1, 7.1.1, 2003.06.00, 2003.06.16

Operating system(s): AIX, HP-UX, IRIX, Linux, Solaris, Windows

Reference #: 1147137

Modified date: 25 March 2010


Translate this page: