-
Bug
-
Resolution: Fixed
-
Blocker
-
5.2
-
None
-
None
-
-
Empty show more show less
-
5.2-rc2
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.
- is causing
-
MAGNOLIA-5523 Remove permissions for no longer existing workspaces (openWFE)
- Closed
-
MAGNOLIA-5539 Remove permissions for no longer existing workspaces (openWFE)
- Closed
-
MGNLUI-2467 Cannot deny access to a node
- Closed
-
MGNLUI-2468 Security app fails to save when encountering permissions assignment for workspace that no longer exists
- Closed
-
MGNLUI-2488 Security App: Cannot create role with local admin when several attempts are needed
- Closed
- is related to
-
MGNLUI-2467 Cannot deny access to a node
- Closed
- relates to
-
MGNLUI-2438 Revert current implementation of check on user roles
- Closed