[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: |
|
||||||||
| 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)
|
||||||||
| 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
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), Again, this one is also mitigated when superusers manage roles (they can grant anything practically), but needs to be fixed for multi-tenancy scenarios. |