How to restrict VOB read access in ClearCase (Windows Server) ?

Question

Hi all,

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.

Answer 2

What is the impact in having different Domain groups for CC users ?

None except the administration cost (registering every users to many group can be cumbersome).
The fact to have several element with different groups is not a problem in itself.

VOB vB, is read/write access to group gB, read access to group gA, and restricted to everybody else

gB is part of the secondary group of vB, gA is not (means no checkout possible).
770 for a system group including gA and gB (meaning read access for gA, read/write for gB, denied for gC)

read-only or read/write implies protections set by clearcase ("cleartool protect" or "cleartool protectvob"), but "no access" can only be achieved on the system level (chmod 770)

ClearCase regions have nothing to do with data restriction, only data visibility: it allows you to see only a subset of vobs or views, it does not prevent you to access them (a simple mktag -vob and you would see that "confidential" vob anyway)

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

Sigh... the CM should stay away, but the CM team cannot always stay away ;) That team must at least initialize the request, for the system team to register the user in the correct group. That initialization step alone is quite a drag, compared to a VCS which has its own group management system. But ClearCase is not there yet.