Question

I have been asked to look at how to restrict read access on certain VOBs in ClearCase, for compliance reasons (so this needs to be auditable, etc, etc…). I have found a solution so far, that I will post here, but I still have questions, so any help would be appreciated. Especially as the devil is in the details, I think.

For ease of argument, let say we have 3 VOBs, and 3 groups:

• gA and gB are two special group, all other CC users are in gC, which is the default CC group
• VOB vA, is read/write access to group gA, and restricted to everybody else
• VOB vB, is read/write access to group gB, read access to group gA, and restricted to everybody else
• VOB vC, is read/write access to everybody

Unaswered questions:

• What is the impact in having different Domain groups for CC users ? When people log, their clearcase group is picked-up by the user variable CLEARCASE_PRIMARY_GROUP. If they are from gA and are working normally in vA, this variable will be set up to gA, but if they need to change something in vC, I bet that the group ownership of their files/versions in vC will stay gA if they don’t do anything about it. Objects in vC will end up having group-belonging to gA, gB, gC. Can that be a problem ?

• I am not even sure it is possible to set up ACLs properly on vB without in fact creating a new group, gA’ containing people from both gA and gB, am I right ?

• It seems to me the difficulty here is not technical, but rather that in the process for giving access to certain people to the proper groups, and that the CM team should stay away from this (and leave that to be decided by the Security Department and the development teams involved). Anyone has any experience in this matter ?

• It seems that it is possible to use ClearCase Regions to achieve the same effect. How would that work ?

Best regards,

Thomas

Answer 1

So far, I have found this answer from the IBM developerworks forums:

(edited)

1. Create two additional Domain groups for the teams

2. Add the appropriate new Domain group to each ClearCase user’s groups profile (in addition to the gC group membership they already have).
   You’ll want the vobadmin account to be a member of both these new groups.

3. Change the group ownership of the VOBs accordingly:
   cleartool protectvob -chgrp group_name <\\..vob.vbs>
   gA for vA
   gB for vB
   gC for all other VOBs (it should already be the case)

4. Remove the “other groups” permissions from the root element of
   the vA and vB VOBs:
   cleartool protect -chmod 770 <vob-tag-name>
   You can also do this by using CC Explorer: right-click on the VOB in
   any view and select “Properties of Element”. There’s no need to
   re-protect the entire VOB (Note: this is important for me, because reprotecting the whole VOB takes a long time, and I have more than 200 VOBs here).

Now, only members of the gA group will have access to the vA VOB.
Only members of the gB group will have access to the vB VOB.
Everybody is a member of the gC group so everybody will have access to all
other VOBs.

Note that you will want to set the CLEARCASE_PRIMARY_GROUP environment
variable for a particular user if you want newly created objects by that
user to be owned by a group different from that user account’s Primary Group
as it is set in the Domain Controller.