[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: PNG File ACL-rights.png     PNG File access-all-areas.png    
Issue Links:
Relates
relates to MGNLUI-2438 Revert current implementation of chec... Closed
causality
is causing MAGNOLIA-5523 Remove permissions for no longer exis... Closed
is causing MAGNOLIA-5539 Remove permissions for no longer exis... Closed
is causing MGNLUI-2467 Cannot deny access to a node Closed
is causing MGNLUI-2468 Security app fails to save when encou... Closed
is causing MGNLUI-2488 Security App: Cannot create role with... Closed
relation
is related to MGNLUI-2467 Cannot deny access to a node Closed
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.


Generated at Mon Feb 12 08:55:48 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.