Does order in perforce's protection table matters ? I mean does it matter if I have some write permissions then read then super then list again then write then admin ?
write user * * //...
read user emily * //depot/elm_proj/...
super user joe * -//...
list user lisag * -//...
write user lisag * //depot/elm_proj/doc/...
admin user admin * //...
=write user joe * -//depot/build/...
or it has to be systematic like this:
list user lisag * -//...
read user emily * //depot/elm_proj/...
write user * * //...
write user lisag * //depot/elm_proj/doc/...
=write user joe * -//depot/build/...
admin user admin * //...
super user joe * -//...
I am new to perforce and when I read Administering Perforce: Protections I do not see any reference to ordering mentioned here (Unless I overlooked something and missed it completely).
I got this question because thinking the way CSS work, if two entries are mentioned for same html element, then the last entry is the one which is taken into action. Similarly, does it matter here with perforce protection table also ?
If you're using exclusionary mappings, like the ones where the depot path begins with a '-' character in your example above, then order is significant. From the Perforce online documentation:
When exclusionary mappings are not used, a user is granted the highest permission level listed in the union of all the mappings that match the user, the user's IP address, and the files the user is trying to access. In this case, the order of the mappings is irrelevant.
When exclusionary mappings are used, order is relevant: the exclusionary mapping overrides any matching protections listed above it in the table. No matter what access level is being denied in the exclusionary protection, all the access levels for the matching users, files, and IP addresses are denied.
If you use exclusionary mappings to deny access to an area of the depot to members of group1, but grant access to the same area of the depot to members of group2, a user who is a member of both group1 and group2 is either granted or denied access based on whichever line appears last in the protections table.
Related
This thread points to a webpage that no longer exists: How to change a perforce user to superuser
How do I change the Perforce Protections Table?
Run p4 protect, and add a line like:
super user joe-bob * //...
Each protection entry has five parts:
the access level (super)
whether the entry is for a user or a group
the name of the user/group (joe-bob)
the client IP range this entry applies to (usually * for "everywhere")
the depot path this entry applies to (there's no point in restricting super access to a narrow path since they have permission to edit the protection table themselves anyway, so for super entries this is almost always //...).
I've been struggling with this off and on for months, and it may be non-trivial to answer.
What is the easiest way to limit public access to an item and its subitems to members of a single role? (Editors still need to be able to edit the item.)
e.g. There's a role, extranet/clubmember, and items,
- Clubhouse
| - Items
| - Inside
| - Clubhouse
And I want extranet/clubmember members to be able to read the items and subitems, sitecore/* members (Or, say, sitecore/editor) to have edit access, and everyone else (in default and extranet domains) to be denied.
Second, does this solution still work with a custom role and membership providers for extranet? Why or why not, or what methods do I need to implement? I recall from earlier experiments that my custom role provider seems to affect Inheritance permissions in particular.
Have you tried the following:
uncheck Inherit for Everyone (the global one) to Clubhouse root
explicitly allow Read for extranet\clubmember to Clubhouse root
explicitly allow Read/Write for sitecore\Everyone to Clubhouse root
Explicit assignments always win. So, that scheme should have the effect you expect.
Consider user is denied access to a table of financial secrets:
SELECT * FROM Transactions
SELECT permission denied on object 'Transactions'
No problem:
CREATE VIEW dbo.Transactions2 AS SELECT * FROM Transactions
Command(s) completed succesfully.
SELECT * FROM Transactions2
(84,387,982 row(s) affected)
Are users supposed to be able to bypass deny permissions on a table by aliasing the table?
Edit: Sauce:
This is working as advertised
It's called "ownership chaining"
dbo owns both table and view/function/stored proc
view/function/stored proc references table
table permissions are not checked at all (for GRANT, DENY, whatever)
If you don't want someone to see a column/table, don't have it in the view/function/stored proc. Or add logic/joins to check permissions according to whatever model you've used.
Previous answers: one, two
It's been in SQL Server and Sybase since, well, long time.
Isn't this part of the intent of views in the first place? To enable visibility to certain, specific information from tables when the user does not otherwise have select permissions on the underlying table(s)?
Sounds like the problem here is that the user in question has rights to create a view in the first place.
For example, say you wanted to expose the non-confidential information in that table; you could do that with a view that limits the results only to what you wanted to be seen.
I know that a list permission can be changed. But it there a way to completely omit a user to see a list. Example - USer A can see Event List but User B cannot see it. Can this be done? Your suggestions will be helpful. Thanks,
If the list has unique permissions (i.e. not set to inherit from it's parent) then the permissions can be configured to only allow groups which do not include User B.
One this is done, User B will not even see the list - they will be unaware that it exists.
If User A forwards User B a direct link to the list, User B will be instead be redirected to the AccessDenied.aspx page.
As MSDN states, then WriteSecurity has 1 of 3 states possible:
1 — All users can modify all items.
2 — Users can modify only items that
they create.
4 — Users cannot modify any list
item.
But if I want behavour nr. 2 plus users can modify items that are assigned to them? Well if I grant a user full permissions (put in owners group) for list, then those can edit any item (not good). So why wouldn't it work by setting item level permission "full control" just for AssignedTo user (good)? I did, but that didn't help - access denied.
I want exactly the functionality as stated in question "Automatically set list item permission, after new item is created", quoting:
Every users (Supervisor and team members) can see any tasks.
Supervisors can edit any tasks
Team members can only edit their own tasks (tasks that were assigned to them, or created by them)
but although answer has been accepted, the solution does not provide a way for users to edit items assigned to them or items created by user.
Help is appreciated, thank You!
Your only way to do this is using Item-Based Permissions. E.g. have a Workflow or Event Handler change the permission on each file/object based on your requirements.
The solution you quote from the other task is simply setting 2 for SPList.WriteSecurity which still doesn't give users the possibility to edit something they have not created, but were assigned to - in this case you will need to give these users permission, e.g. by listening on the "Assigned To" field with an Event Handler (OnItemUpdated) and give the respective person the needed permission.
Furthermore the solution talks about just setting higher permissions for the users who should always be able to edit items (managers), which is a solution, but you do not have the granularity you usually want in situations like these.