[MGNLUI-2357] Check user permissions when saving ACLs Created: 06/Nov/13 Updated: 11/Sep/20 Resolved: 20/Nov/13 |
|
| Status: | Closed |
| Project: | Magnolia UI |
| Component/s: | None |
| Affects Version/s: | 5.2 |
| Fix Version/s: | 5.2 |
| Type: | Bug | Priority: | Blocker |
| Reporter: | Lars Fischer | Assignee: | Philip Mundt |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | 1.35h | ||
| Original Estimate: | Not Specified | ||
| Attachments: |
|
||||||||||||||||||||||||||||||||||||||||
| Issue Links: |
|
||||||||||||||||||||||||||||||||||||||||
| Template: |
|
||||||||||||||||||||||||||||||||||||||||
| Acceptance criteria: |
Empty
|
||||||||||||||||||||||||||||||||||||||||
| Task DoD: |
[ ]*
Doc/release notes changes? Comment present?
[ ]*
Downstream builds green?
[ ]*
Solution information and context easily available?
[ ]*
Tests
[ ]*
FixVersion filled and not yet released
[ ] 
Architecture Decision Record (ADR)
|
||||||||||||||||||||||||||||||||||||||||
| Bug DoR: |
[ ]*
Steps to reproduce, expected, and actual results filled
[ ]*
Affected version filled
|
||||||||||||||||||||||||||||||||||||||||
| Date of First Response: | |||||||||||||||||||||||||||||||||||||||||
| Sprint: | 5.2-rc2 | ||||||||||||||||||||||||||||||||||||||||
| Description |
|
In securityApp, in the dialog for editing roles and access control lists a user can type paths into edit fields. When closing the dialog and saving the edited ACLs there must be a check that the logged in user does not assign "higher" user rights to a role that he himself has. Scenario: A "local" (multi-tenancy) admin restricted to administer roles contained in the folder "/departmentOne" creates a new role and assigns Read/Write access for all the available objects on the root ("/") node (like in the superuser role). In addition to that, under "Web Access" he grants "Get&Post" to "/*". Assignment to an editor: After assigning this role to an editor, the editor does not get superuser rights but can see all the websites and all the assets, not only the ones he should see. Assignment to himself: The local admin assigns the newly created role to himself and then is able to access all areas of the securityApp. So we need to implement a security check to prevent such "options" in a multi-tenancy environment. A solution might be to compile all access rights of the logged in user account and compare them to the ones that are going to be assigned to a security object. |