[MGNLUI-3395] WritePermissionRequiredRule incorrectly skips superuser role from the checks Created: 03/Apr/15 Updated: 01/Jul/15 Resolved: 30/Jun/15 |
|
| Status: | Closed |
| Project: | Magnolia UI |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | 5.3.10 |
| Type: | Bug | Priority: | Neutral |
| Reporter: | Jan Haderka | Assignee: | Milan Divilek |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| 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: | |||||||||||||||||||||||||||||
| Description |
|
Which permissions superuser has is actually governed by the setting, but somehow there is a shortcut in the rule that essentially forbids controlling permissions for anyone who has superuser role even when setting such permissions in the role itself. |
| Comments |
| Comment by Jan Haderka [ 08/Apr/15 ] |
|
To be merged to 5.3.x after review. Fix on branch is against master/5.4. |
| Comment by Mikaël Geljić [ 21/Apr/15 ] |
|
Code review:
To save time, I did those changes already and pushed them to the branch. History/QA:
Unfortunately, this still holds true if we simply remove the check. |
| Comment by Milan Divilek [ 12/May/15 ] |
Superuser role has read/write ACL to root of userroles repository, but e.g. forum_ALL-admin role has only read ACL to itself. The problem is that if superuser user has both roles (superuser and forum_ALL-admin) then the read-only ACL (from forum_ALL-admin role ) is applied, because the ACL with the longest pattern determines the permission. |
| Comment by Mikaël Geljić [ 12/May/15 ] |
|
That's the way to go |
| Comment by Mikaël Geljić [ 13/May/15 ] |
|
| Comment by Milan Divilek [ 19/May/15 ] |
Component info.magnolia.ui.api.availability.AvailabilityChecker is defined for subapp container In ui-framework module descriptor. So using app-security container had not effect and that's why it was defined for those 4 subapps in security-app. |
| Comment by Mikaël Geljić [ 15/Jun/15 ] |
|
Well, sadly I haven't got time to get back to this one myself, so I'll quickly drop a comment: So extending the AvailabilityChecker was the way to go. Hope that helps, sorry for "holding" that in review for that long :/ |
| Comment by Milan Divilek [ 26/Jun/15 ] |
That wouldn't help. Shorthand (default) rules need to be defined globally in the class, because they are in certain use cases removed from list of rule in info.magnolia.ui.framework.availability.AvailabilityCheckerImpl#isAvailable method. See // Since we can't combine rules with AND/OR operands, 'root' availability should keep precedence over nodes/nodeTypes-allowed rules when the default item is selected. if (definition.isRoot() && idsToCheck.size() == 1 && ObjectUtils.equals(idsToCheck.get(0), defaultItemId)) { rules.remove(jcrNodesAllowedRule); rules.remove(jcrNodeTypesAllowedRule); } So if we don't want instantiate shorthand rules via Component provider then making shorthand rules protected is best and easiest solution without rewriting whole info.magnolia.ui.framework.availability.AvailabilityCheckerImpl. I just reverted the commit which introduced instantiating shorthand (default) rules via Component provider. |