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.
Related
Depending on the user, report data is missing when viewed via the dashboard.
-In security settings I gave organization-wide read/write permission.
-The reports are based on a two custom data objects with a master/child relationship (which is also set as read/write.)
-The report folder is also set as "read/write" and all users have permission.
Anything else that I forgot to check?
Thanks!
What error do you experience? "Insufficient privileges"? Or maybe report loads fine but just shows 0 rows?
When drilling down to the detailed report you need to make sure that
viewing user has at least Read permission in his Profile on both the master and child object
he must also has read permission to all fields used in the report (columns as well as filters. And if any of them is a formula -> check their source fields too).
Does the report use "My Opportunities" in the filters? Or unrealistic date criteria? If the dashboard wasn't refreshed in a while even date filters can cause you grief.
In some cases the Roles hierarchy is saved with the report - if the user sits in different branch of the role hierarchy than the dashboard's running user, you might have to flip it to your top level Role for example. Run the report, examine top part for Role names, adapt if needed and save it.
Perhaps the best way is to debug it is to login as this user and try to recreate this report from scratch. If you can't even select proper report type - this looks like scenario 1. If fields are missing - 2.
What I need
I have a custom Entity with that with multiple fields. Admin Role has "god" access. All other roles except for one have read only. The one non admin role with update access, should only be able to update a single field.
What I believe to be true
I believe I have three main options to implement this requirement:
Enable Update Access to the role for that entity then write Javascript to disable all fields on the form for that role, except for the one that I want that role to be able to edit
Enable Update Access to the role for that entity then create a new form that disables all fields on the form for that role, except for the one that I want that role to be able to edit.
Enable Update Access to the role for that entity then turn on field security for each field, disabling access using the field security, for each field except for the one I want them to edit.
What's the Best Practice?
What options should I choose?
If I go with options 1 or 2, will the user be able to edit the field on the bulk edit form?
From a user perspective, I think it's confusing when a form opens up with things enabled, then they get locked down. Plus someone could possibly get data in there before the fields get locked. I'd say you'd have to combine this with a plugin to prevent changing fields you don't want changed.
I like this option better, although again, the field can be unlocked if someone knows what they're doing, so a plugin to double check would be nice.
This would avoid having to double check in a plugin, but you also have to rely on the admin correctly setting up security for new fields going forward. If that's not a concern, this might be best.
Bulk edit is a global privilege, so they'd have bulk edit for all entities. Also, the bulk edit form does not load scripts, so that knocks out option 1. I'd say if it's just this one field, I might leave the privilege locked down and provide my own Bulk edit button on the grid that would show a custom page that just has that one field on it, then handle the updates though script.
2 is most likely best, or as an alternative put the fields in the header or footer rather than as read-only fields on the form.
This also means the fields won't be available to bulk edit, but other methods such as data import or workflows would let users get round this if they know how and have rights to do such things.
3 Field Security is the most robust and works for all scenarios
Possible option 4: create another entity to contain those fields and apply different security to that entity. If created as a child, show the record in a grid on the form with the values included in the view. If it is a parent then you could use methods such as showing the values via an HTML webresource page included on the form.
I'm programming a new application with many users, a few roles and specific permissions for those roles. For that I want to create the following tables:
Users (ID,Login, password,..)
Roles(ID,Rolename)
User_Roles(User_ID, Role_ID)
Permissions(ID,PermissionName)
Permission_Roles(Permission_ID, Role_ID)
My idea was to build a function, which allows to check if a user has a specific permission to access a form. I would do that by creating Permissions/Rules like 'canReadFormX', 'canEditFormX' which would allow me to use one main function to check and perfom those specific rules and a function per form to call it.
Is that a way to go (or rather did I understand everything correctly regarding RBAC) or is that just far to complicated? Any advise is very appreciated!
It seems fair to me, and similar to what we have already set, for the first 3 tables.
You then have to solve the 'action' problem, ie to distribute permissions to use your appl's actions. I am not sure that your 'Permissions' proposal will cover all the situations, as you have to deal with 2 major categories of actions:
The 'Open form' actions, that you already have identified: you effectively have to define 2 levels of authorisation for each form: the 'view' right, and the 'update' right.
All other actions, such as form specific buttons or menus, that will allow you to run a specific action other than just opening a form (execute a report, make a specific calculation, automatically import or update data, etc).
One solution/My advice is to maintain 2 tables for this:
A 'Forms' table
An 'Actions' table
And the corresponding link tables:
A 'Form_Role' table
An 'Action_Role' table
With such a configuration, you are fully covered. You can even decide which role has the right to see a specific report on a specific form, as long as the corresponding action is accessed through a specific control or menu on the form.
Both Forms and Actions tables are very interesting as they both participate in your application metamodel...
EDIT: By the way, if you are on a domain, you can use user's domain credentials to control his\her access rights to your system. In this case you do not need to store a password in your RBAC system.
( Regarding Moss 2007 )
i have created a sharepoint list in which one column is called user assigned - this is a lookup column of type - people and group.
i select the users from active directory to enter this field of the list.
So different items in this list have different users assigned
I have create permissions for this list to be read and write to the users in active directory .
so that when a particular user logs in to the sharepoint website with his credentials. he has read and write access to the list.
Now is there any way available in sharepoint by which the user do not see the whole list when they login to the website . He only sees the items of the list which the user assigned field is him only.
If the permissions are indeed setup right, you only have to go to List Settings, Advanced Settings, Item-Level Permissions and on "Read access: Specify which items users can read" you define their own.
If the users are not the creators of the items, you need to go to List Settings, Views (at the far bottom), modify the All Items View (or w/e you have as default), go to the filter section and add a filter like: "Show items only when the following is true", "Show the items when column" Assigned To is equal to [me]
I've been implementing such solutions for some while. It is possible, but
it takes much work to be done
if used in long term and/or the amount of data is large, this will hit performance
If none of these is a problem for you, then you can:
create code which performs BreakRoleInheritance() on the item, then adds ViewListitems permission for the user in "user assigned" column. You can find example code, for instance, here: http://social.msdn.microsoft.com/Forums/en/sharepointecm/thread/581e456c-db3c-44f1-b958-a824d95a2536 (or search in Google for "SPPrincipal" and "SPRoleAssignment" for more info)
make this code be called whenever the item is added or updated (you have to wait for the "-ed" events, because in the synchronous version of these events you can't change the permissions yet, for instance in "ItemAdding" there is no item created yet). You can achieve this by adding an event handler to the list.
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.