I have a requirement to create an authorization system on directories. Each directory can have child directories and/or files. There are 4 types of permissions available on the directory/files - Add,Update,Delete,Read. Permission can be granted to multiple users and/or multiple groups. I want to create a schema in DynamoDB table that allows me the following operations:
Add - On adding a new directory/file, all default (Update, Delete, Read) permissions be assigned to the owner.
Delete - User should be able to delete a directory or file. When deleting a directory, all child components should also be deleted.
Update - User should be able to update the permissions on a directory/file.
Read - User should be able to list all directories/files on which he has any kind of access.
Read - Given a file/directory name, username and the permission, system should return whether the user has the requested access on the file/directory.
I could think of a composite key and one GSI that would solve this for a flat structure but I need to implement this for a hierarchy of folders. Thanks in advance.
Related
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
I have a split database design in Microsoft Access. Copies of the front end (w/ forms, queries, linked tables) are distributed to multiple users, while the backend (tables only) resides on the network.
Everything works fine when there is only one user, but as soon as a second user tries to open their copy of the front end, they get an error message saying the backend is already in use.
I've already confirmed that everyone has read & write permissions for the backend.
I've used split databases before and never run into this issue. The only difference is this time I didn't use the Database Splitter utility. I just started with the backend, then created a new database and set up some linked tables. Could that be my problem? Is there a step or setting I'm missing?
In general, this should work.
However, not only do users need read/write, but they ALSO require create file, and delete file rights to that folder.
The reason is that of couse this is pure file based system, so on first open, Access will create a ldb (locking file). This locking file is used to manage (allow) multi-user operations of the file.
If the locking file can't be created (first user to open), then multi-user operations can't be used, and in fact in most cases you get a read-only file.
So, users need quite much full rights. I seen some work with delete rights, but that means the last user out does not allow access to remove (delete) that ldb locking file, and it should be allowed for deletion.
so, create file, delete file rights are also required in most cases for this to work.
It also possbile I suppose that one user launched Access, choose open, and browsed to that file, and opened it exclusive. However, you have a split system, and that should not be possible, but it certainly still possible that someone on the network opened the back end file (that shared file) directly with Access, and used the open exclusive option - which would prevent all other users from opening the file.
As noted, since this looks to be a split system, then I would suggest that users don't have the all important create file rights, and delete file rights to that folder. Without such rights, then as noted, multi-user operations can't occur - you get a read only file in most cases.
So, either users don't have enough rights to that folder, or someone has opened the file with Access, and opened the file "exclusive".
If somebody want to manage permissions in a program first idea would be RBAC implementation. but another idea is a service like NTFS which allow to any user to create and manage his/her directories and sub directories. moreover can add more users with defined access
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"
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.