[MGNLUI-3980] Consider loosening validation of recursive deny permissions Created: 11/Aug/16  Updated: 24/Mar/23  Resolved: 15/Mar/21

Status: Closed
Project: Magnolia UI
Component/s: security app
Affects Version/s: 5.4.8
Fix Version/s: None

Type: Improvement Priority: Neutral
Reporter: Mikaël Geljić Assignee: Unassigned
Resolution: Won't Do Votes: 0
Labels: acl
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: PNG File denying-ws-permissions.png    
Issue Links:
supersession
supersedes MGNLUI-3838 Wrong ACL-validation results in Acces... 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)
Testcase included:
Yes
Epic Link: Security maintenance

 Description   

A. For a custom admin, assigning a deny permission to a fixed node/path requires read/get permission to that node. So far so good.

B. Now, since MGNLUI-3838:

We now validate sub-node permissions in a more fine-grained way: in particular, in order to grant a sub-node permission (say RW on /foo sub-nodes), admin must not have any permission to a sub-path of that node, with lower permission (RO on /foo/bar). This way, we now also ensure admins cannot lift their own restrictions by assigning higher-level recursive permissions to another user/role in their control.

If I get this straight, A. and B. combined mean that the validator converts deny requirement to read, then current user's deny permissions get considered as violations, being lower than read.

Given a custom admin role with Deny access to /foo/bar (right-side of the screenshot),
a custom admin user cannot deny permission to /foo (left-side of the screenshot).
I believe he could, as this cannot lead to lifting one's restrictions.

Again, this one is also mitigated when superusers manage roles (they can grant anything practically), but needs to be fixed for multi-tenancy scenarios.


Generated at Mon Feb 12 09:12:04 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.