clearcase additional group & group security

[Anand Mehta]

I have few users who are shared resources in couple of projects.
I am implementing project security on the VOBs.

for each vob, we have different Primary_Group. so only users of that group can access the vob.

e.g.
we have individual VOBS for each project. Proj1 has VOB1 and Proj2 has VOB2.
user A is member of both projects Proj1 and Proj2.
Primary group for VOB1 is VOB1_Users , VOB2 is VOB2_users.

i.e. he needs access to both the VOBs simultaneously.

but other members of the project only need to access their respective vob.

how can we achieve this for user A without having him keep on switching the PRIMARY_GROUP?

Scenario 1:
even if we add userA to both the primary groups VOB1_Users & VOB2_users, he still would have to keep switching his primary_group variable for accessing each vob.

Scenario 2:
use of Additional group.
this doesnt help in our scenario.

As per IBM, Additional group members can only Mkelem, but cannot checkout files.

What is the purpose, where is the Additional group used in the real world ? any eg / scenarios ?

Can you please suggest me anything on this.


Regards,
-Anand.

[Brian Cowan]

Well, your primary group is used to determine if you can make new
elements. if your primary group is in the VOB's group list, you are able
to create new elements. This is the only official purpose for the
primary group.

So, as you said, the VOB's group list is used to determine who can
create new elements in the VOB.

So, it user1 needs access to vob's A and B, you would
1) add him to the VOB-specific groups for those VOBs, and
2) make sure that the VOB root directory elements had 550 or 770
permissions. (Note: xx0 permissions have issues in Multi-Domain Windows
configurations.)

Then, as long as he doesn't need to add new files to source control,
he'll be fine. If he does, then -- officially -- he'll need to change
his primary group to the VOB-specific group before adding files to
source control. Unofficially, if you are on Windows, running CC 7.0.x,
you may not have to change the primary group since there is fallback
logic that allows the mkelem command to check your entire group list for
one that has permissions to make new elements.

The problem with 1-group-per-vob configurations is that they don't
scale. On Unix, you run out of steam at 16 or 32 groups, depending on
your Unix flavor. ClearCase on Windows is runs out of steam at 32 groups
-- Windows itself will allow you to be a member of hundreds of groups,
but Clearcase will only "see" the first 32. So, you have to look at your
requirements at a higher level to see how to work around this.

Hope this helps...

[Anand Mehta]

Hi Brain,
Thanks for the prompt response.

I realise 1-group-per-vob configurations is not the best way to configure security with respect to the 32 group restrictions.
you may follow this link from IBM dev works...  http://www-1.ibm.com/support/docview.wss?uid=swg21131881
It talks of the "clearcase_group" variable which can be set to overcome this restriction to some extent. You can do well, unless you exceed being a member of 32 clearcase groups (not windows domain groups). you can list all the clearcase groups in this variable. Clearcase will first look for this variable value then go with the creds group listing.

As per your instructions, we added user A to VOB A and VOB B. with the 770 permission on the vob storage directory. - ( this is done by cleartool protect chmod 777 .. right ? )
It works perfectly as you mentioned. user A is able to access both the VOBs A and B. also since we use CC7.0 ifix it also allows for mkelem.

Thanks very much for the solution. Appreciate your help.

one query,
If we do not go with 1-group-per-vob configurations, how do we attain security between the groups?

Regards
-Anand.

[Marc Girod]

Hi,

On Jan 11, 7:57 pm, "Anand Mehta" <anmev.me...@gmail.com> wrote:

> If we do not go with 1-group-per-vob configurations, how do we attain
> security between the groups?

I would suggest to reconsider what you mean by 'security',
and whether using groups actually buys you more than it
costs.

Specifically, when (at what grain) is it better to hide some
information, than to show it?
When is it better to control than to manage?
(Control is exclusive, management collaborative.
The more you control, the less I control;
the more you manage, the more I manage.
The more one controls, the less one manages)

A tool for controlling in ClearCase, albeit not read access,
is locks. An other is labels.
Both kinds of objects may be owned by accounts
distinct from the ones recorded with the data changes.
Switching ownership for the purpose of running one
command can be enabled via sudo (unix) or RunAs
(Windows).

Marc