cleartool protectvob 2 different results

Question

I am trying to perform a build of some software that exists on an air gapped network. And I having issues with clearcase, denying me access to files that I need to perform the build.

When I check the protection settings for the VOB on the clearcase server I get:

Pool "sdft" appears to be protected correctly
Pool "ddft" appears to be protected correctly
Pool "cdft" appears to be protected correctly

looking at that same vob from the windows side I see:

Pool "sdft" needs to be protected correctly
Pool "ddft" needs to be protected correctly
Pool "cdft" needs to be protected correctly

Before seeing this issue there was a problem with VOB caused because active directory had been modified so I recently changed the ownership of all of the files in the VOB to me. and according to a sidwalk/looking at the files from the linux side. It looks like I have the correct permisions set."

What can I do to fix this issue?

EDIT learned old information was relevant: This was not included because I didn't think this was related.

Before trying to get things working on this system, there had been a software update which had broken the active directory configuration. Which was fixed and gave me access again to ClearCase and the ClearCase Server

Answer 1

I feel bad, that due to some missing information on my part.

The missing information

This network uses active directory to keep the users synchronized between devices... But a software update broke it. So we had to create a new configuration. This ended up creating a 2nd identically named group to the group that owned the clearcase VOBs. Looking at the files on the ClearCase server side, protectvob saw that the username was what it was supposed to be, the group name was what it was supposed to be, no problem! It didn't realize that clear_case_group(gid=1) is not clear_case_group(gid=2).

The windows side however had no idea who clear_case_group(gid=1) is and so realized that there was a problem.

My attempts to us fix_prot to fix that access errors failed, because fix_prot was applying the gid from clear_case_group(gid=1) to the files and not the second, newer group.

How i found out that this was the actual problem

1. id questor soon after looking at a sidwalk dump and noticed thatclear_case_group had a different GID for questor then inside of the dump file.

2. getent group clear_case_group, questor was not a part of the group... But

3. getent group <gid=2> -> clear_case_group that questor was a part of...

4. getent group <gid=1> -> clear_case_group that questor was not a part of.

There are 2 clear_case_groups on the ClearCase server for some reason (terrible practice, I know).

The Fix:

vob_sidwalk used to replace clear_case_group(gid=1) with clear_case_group(gid=2), or fix_protect using GID instead of group_name...

Lessons learned

Group names do not have to be unique on Linux. Linux allows for duplicate group names with different GIDs. This is my first (and hopefully only) time encountering identically named groups. SO before making a claim that the user/groups are correct.... Look at the GIDs which are unique not the names.

Answer 2

This is somewhat stream-of-consciousness and being edited on mobile, so bear with me.

Without knowing WHY you are "denied access" resolution attempts may make thing worse.

Those outputs are from protectvob, and would have to be taken with a grain of salt when run from windows if the VOB is in Unix.

The describe of the VOB is the first step. Look for "nobody" in the user and groups. These are groups that are not mapping. Then describe the file you are trying to access. Does its group map? Are you a member of the group? An element group that doesn't map between windows and UNIX will block cleartext construction.

Are you the only person with access issues? When did they start?

Does Creds ({cc install}\etc\utils\creds) show you in that group?

If this is happening in dynamic views, and everything else looks right, how are you logging into Windows? If you're using biometric, smartcard, or Windows Hello authentication, the clearcase primary group and/or clearcase groups environment variables will only partially "take" until you invoke the nplogon.exe utility in \windows\syswow64. The above login mechanisms bypass this, and you can have mismatches between what creds sees and what the MVFS sees.

Answer 3

Check the primary group of the VOB: cleartool describe -long vob:<vob-tag>

Your ACL should at least reflect that group.
See "About ClearCase permissions on Windows"

Security descriptors contain information about ownership of objects: who owns the object, who can access the object, and the types of access allowed for the object.
A discretionary access control list (DACL) is a component of a security descriptor which is viewable and modifiable by users with read access to the object.
Note that the terms DACL and access control list (ACL) are used interchangeably.

VOB and view storage directories (ending with .vbs and .vws) use identity.sd and groups.sd files that describe ownership, regardless of the file system on which they reside.
The contents of these files can be viewed using the lsacl -f command.

That last command is detailed in "Fixing protection problems"

If the filegroups.sd exists in the storage directory root stg-pname, run this command:

ccase-home-dir\etc\utils\lsacl –f stg-pname\groups.sd 

Example:

===== stg-pname\groups.sd                        (Owner)
Owner: NT_WEST\bob (User) (non-defaulted)        (Primary group)
Group: NT_WEST\usersnt (Group) (non-defaulted)
ACL (revision 2): 
0: allowed 
SID: NT_WEST\user (Group)                        (Supplementary group)
rights (00000000)

1: allowed    
SID: NT_WEST\tester (Group)                      (Supplementary group)
rights (00000000) 

===== stg-pname\groups.sd                        (Owner)
Owner: NT_WEST\bob (User) (non-defaulted)        (Primary group)
Group: NT_WEST\usersnt (Group) (non-defaulted)   
ACL (revision 2):
Empty ACL: all access denied                     (No supplementary group)

3. Remove the supplementary group list. Run the following command:

   ccase-home-dir\etc\utils\fix_prot –r –root –chown owner –chgrp group stg-pname
   

   • If you are fixing view storage, you are finished.

4. If you are fixing VOB storage, log on as the VOB owner and continue.

5. If the VOB has a supplementary group list, run this command:

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

6. Remove the cleartext containers. Run the following command:

   scrubber –e –k cltxt vob-stg-pname
   

   This step must precede Step 7 because checkvob cannot fix cleartext containers.

7. Fix the storage pools protections. Run the following command:

   cleartool checkvob –force –fix –protections –pool vob-stg-pname