[SERVER-13696] Allow revoke/deny role permissions Created: 23/Apr/14 Updated: 06/Dec/22 |
|
| Status: | Open |
| Project: | Core Server |
| Component/s: | Security |
| Affects Version/s: | None |
| Fix Version/s: | features we're not sure of |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | John Butler | Assignee: | Backlog - Security Team |
| Resolution: | Unresolved | Votes: | 5 |
| Labels: | security | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||||||
| Assigned Teams: |
Server Security
|
||||||||||||||||||||||||
| Participants: | |||||||||||||||||||||||||
| Case: | (copied to CRM) | ||||||||||||||||||||||||
| Description |
|
Allow deny/revoke privs to apply to roles. Since the current system has "grant" based roles implicitly there is no way to do this now without explicitly specifying each resource (db/collection) ahead of time. Orig |
| Comments |
| Comment by Sander van Loo [ 23/Nov/21 ] |
|
We have a large cluster with software creating databases at run-time (when new datasets are onboarded to the application). We need to ability grant access to these databases based on their information security classification (which the application is aware of). For this to work, the application needs to be able to create/modify roles. |
| Comment by NOVALUE Mitar [ 07/Sep/16 ] |
|
We would also need this. This is my use case: Currently you can only assign permission users, but you cannot take them away. I would like to have an user which can create any collection, do anything with them, but for one particular collection they should be able only to insert new documents into it, not update or delete them. Currently it seems this is not possible. |
| Comment by John Butler [ 23/Apr/14 ] |
|
This would work. I could grant overall drop DB permission but deny it for as specific DB. As long as the deny (being more specific) will take precedence over the allow. |
| Comment by Scott Hernandez (Inactive) [ 23/Apr/14 ] |
|
John, I've updated this to a generic version of what I think you wanted. Let me know if this correctly addresses your needs, and also makes logical sense. This description if more in-line with other ACL/Permission+Role security systems which I've seen before and should be easier to understand I believe. |