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
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.
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
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.
getent group clear_case_group, questor was not a part of the group... But
getent group <gid=2> -> clear_case_group that questor was a part of...
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.
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)
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.
If you are fixing VOB storage, log on as the VOB owner and continue.
If the VOB has a supplementary group list, run this command:
cleartool protectvob –add_group group-name[, ...] vob-stg-pname
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.
Fix the storage pools protections. Run the following command:
cleartool checkvob –force –fix –protections –pool vob-stg-pname
Related
In my project I got to create users who are allowed to read only access to VOB. To accomplish this as per study and my understandings I have created different groups and directory wise I have changed root group to respective group.
Example : Under VOB I have three directories dA, dB and dC I created 3 groups gA, gB and gC.
Even after gving protecting directories by chmod 770 so that other groups could not do Checkin/Checkout -
1. Other groups users still could access directories.
2. And other groups are still able to do Checkin/Checkout.
Please do suggest on how I can restrict VOB components(directory basis) from checking ou/in by specified user in clearcase.
ClearCase 7.x:
chmod on the vob storage itself isn't enough to prevent checkout/checkins modification operations: you need to consider the CLEARCASE_PRIMARY_GROUP environment variable used by each user.
If that group is not part of the primary group or secondary groups declared in the vob, they wouldn't be able to checkout/checkin.
See also "About ClearCase permissions on Windows".
As mentioned in this thread:
Unless user is a member of the element's group, he or she would not be able to make any changes (checkouts/check-ins).
It can be used to grant read-only access to a VOB, when elements "world" rights are not revoked.
BTW, even when required group membership is not granted, it would not prevent user from creating metadata, such as branch or label types. Triggers would be required to restrict these operations.
This thread confirms:
you are stuck with a pre-op trigger on checkout.
Add the "read-only" users to the group and only allow users in a list (either in the trigger itself or as an attribute on the VOB) to perform checkouts.
ClearCase 8.x
CC8 introduces the notion of access control lists (ACLs), which simplify the security of your versioned object bases (VOBs).
See more with "Ensure effective administration and security in Rational ClearCase 8.0.1"
At our work, we are forced to use Clearcase UCM as our central repository (specifically for labelling/baselining, builds and code reviews), but our team wants to use Git as our real SCM system.
What we want to achieve is essentially a scraping service that takes the commits as they are pushed to our central Git repo, and push them on to a Clearcase VOB that is read-only as far as the development team is concerned, including important information such as the comment and the user name (exact date/time matching is not important, but getting the user correct is).
Our centralized Git server has been configured (using the excellent scm-manager) to accept Windows domain users and passwords, and our Clearcase servers use Windows domain accounts, but I am unsure how a scraper service would "impersonate" the correct user so this information is duplicated correctly in Clearcase.
I thought the chevent command might hold some promise, but that only gives access to the comment.
Is there any way to amend the details of a Clearcase event record once it is in the database, in particular the user-name? Or is there a better way to do this?
Again, we don't need a bi-directional bridge - all access to the Clearcase VOB as far as code commits is concerned would be through the scraper.
ClearCase is a file-by-file SCM, not a revision-based SCM.
(See "What are the basic ClearCase concepts every developer should know?" for a more detailed comparison between ClearCase and git)
That means, for each git commit, you need to:
clearfsimport into ClearCase any file included in the git commit.
Create a specific UCM activty for that import.
As a ClearCase admin, cleartool protect -chown on the activity: see "Why is the owner of the clearcase activity 'nobody'" (as well as a protect -chgrp, if the CLEARCASE_PRIMARY_GROUP environment variable wasn't correctly set at the time of the import).
Note that cleartool protect affects the entire "element" (file or directory), not just one version, so you cannot record the user id that way: the next import would overwrite that id with the id of the new committer whom content is imported.
Plus, you cannot changed the initial creator (see "Changing the name of the original creator of an element")
That means you should record that information (author and creator git id) in attribute:
see cleartool mkattr.
If I did want to accurately reflect the Git user as the "creator" of the new version of the file does that mean I would need a way to run clearfsimport as that user - impersonate them?
Yes: for each commit, you would need to clearfsimport "as" (runas in Windows, as mentioned in this thread) that use, in order for ClearCase to properly set the creator (if this is a new element) or the version author (if this is an update of an existing version).
The reason I didn't mention that possibility in the first place is that I don't have access to the credentials of another user, for me to switch to for each clearfsimport.
Other import tools (CVS, PCVS, RCS, SCCS, SSafe) simply:
ignore that creator/author information entirely.
add attributes of their own for tool-specific information (like the promotion group 'PVCS_GROUP', or RCS_REVISION.
Each time, you will find the limitation similar to:
clearexport_sccs ignores information in SCCS files that is not related to version-tree structure; this includes flags, ID keywords, user lists, and Modification Request numbers
most of our other systems that need the Clearcase history use the creator to reflect who made that change
That means your other systems can rely on the user ID version, except if it is the one used for the import (in which case they would consult the special attribute recording that data from the import)
I am receiving the below error when I am trying to edit the value of Proj_Mgr in UCM.
Please advise
no permission to perform operation "Make attribute" UCM
You must see an error like:
No permission to perform Make Attribute.
Must be one of: member of object group, object owner, VOB owner, member of admin group
So check your CLEARCASE_PRIMARY_GROUP environment variable, and compare it to the groups of the vob, or the associated pvob (in UCM).
You can see those by describing the vob:
cleartool descr -l vob:\myVob
As a possible cause, check out the IBM technote
"Problems that occur if the ClearCase Administrator group owns the VOB or VOB objects":
When a VOB or objects contained within a VOB (elements and metadata) are owned by the ClearCase Administrators group, this will most certainly result in permissions errors whenever an operation is performed against that object by a non-Admin user.
Since the administrators group by default has access to all ClearCase objects, it is not necessary to explicitly add that group and should be avoided.
You can see a concrete scenario where that error pops up in:
"Error setting the recommended baselines for this stream" (for a Stream though. In your case, you shouldn't have to reprotect the Vob, but rather make sure you have the right identity/group).
I used this command to solve this issue (a protection issue as described above):
ct protect -chgrp ccuser project
I am trying to make one folder in our VOB where it is readable by everyone, but only one group can write to it. This is what I have done, but I am starting to think that I missed something...
I had a new windows group created and added the specific users to it.
I added this group to the vob group list. (Does it have to be added to the PVOB as well?)
I changed "group" owner on the folder to this group.
I added this group to my CLEARCASE_GROUPS environment variable (and restarted.)
I am still getting "permission denied" when I update, and I am not able to add any files under the folder. Did I in fact miss a step?
You also need to:
add this group to your CLEARCASE_PRIMARY_GROUP
then create a dynamic view (it will be protected with this group)
then mount this vob
and try to create a folder in it.
See also "How to restrict VOB read access in ClearCase (Windows Server)?" for a concrete example.
I mention a dynamic view because it will be easier/faster to test the Vob access and folder creation with it. Once it is working, create a snapshot view in the same conditions and it should also work.
Note: if this Vob is an UCM component Vob, I would recommend adding that group at least to the secondary groups of its associated pvob.
We have several Windows network shares, in a common location (\\server-name\share) that hosts a common set of files. These shares are replicated across roughly 300 hundred servers. We have the actual replication down, but we're running into an unanticipated problem: server admins half the world away changing file permissions on our share, and breaking replication in creative ways.
To detect this early on, we'd like to write a script to check each server's network share and ensure that a few permissions exist for the share folder & its contents:
Everyone needs read access
User X needs change/modify
User Y needs full control
Now, so far I've got a nice script that checks that at least each share exists. The complication stems from the fact that (due to a nice Active Directory tree), the usernames are consistent across servers (always of the form "DOMAIN/user"), but their guid numbers vary.
So far I've been looking at cacls.exe and the newer version Icacls.exe, but the options are confusing and seem to be centered around changing the Access Control Lists, which I don't want to do. Any tool that's Windows built-in is preferable, I'm just unsure how to approach this.
So it comes down to is: on some arbitrary server, if I only know the NAME of a user, is there a way to figure out what file permissions they have on a given folder?
icacls does allow the use of the "friendly name" form for specifying the user. Which means you should be able to use the human style names. So 'bob' should point to the same person in all of your domains.
You can grant a user a permission without changing anything else using /grant:r which means "if it's already there do nothing, otherwise add it". So,
Everyone needs read access
icacls \a\directory\somewhere /t /grant:r Everybody:(rd)
I assume you want them to be able to list the contents of the directory as well as read.
User X needs change/modify
icacls \a\directory\somewhere /t /grant:r bobX:m
And so on. I assume that 'm' is sufficient to convey the 'modify' permission.
ACLs are just another name for "permissions". So, if you want to change permissions then you want to change the ACLs.