[ https://issues.apache.org/jira/browse/SLING-11160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17499606#comment-17499606 ]
Dan Klco edited comment on SLING-11160 at 3/1/22, 3:17 PM: ----------------------------------------------------------- I agree that the nomenclature is confusing. What about a "remove ACE(s)" command which would take a path along with a principal, optional restriction and optional modifier and remove any matching ACEs from the ACL? >From a consumer perspective this would seem to match the use case better, for >example I may want to do something like: {{remove ACE for users-with-write-by-default with grant on /content}} {{add ACL for users-with-write-by-default}} {{allow jcr:read on /content}} {{end}} {{add ACL for more-restrictive-group}} {{allow jcr:read,jcr:write on /content}} {{end}} So that you could remove the OOTB ACE for a principal and apply a different ACE without removing the ACL entirely and thus run the risk of missing an unrelated ACE when re-adding the ACL. was (Author: dklco): I agree that the nomenclature is confusing. What about a "remove ACE(s)" command which would take a path along with a principal, optional restriction and optional modifier and remove any matching ACEs from the ACL? >From a consumer perspective this would seem to match the use case better, for >example I may want to do something like: remove ACE for users-with-write-by-default with grant on /content add ACL for users-with-write-by-default allow jcr:read on /content end add ACL for more-restrictive-group allow jcr:read,jcr:write on /content end So that you could remove the OOTB permissions granted to a group and apply a more restrictive permission set without removing the ACL entirely and thus run the risk of missing an ACE when re-adding the ACL. > Repoinit does not allow to remove individual ACEs > ------------------------------------------------- > > Key: SLING-11160 > URL: https://issues.apache.org/jira/browse/SLING-11160 > Project: Sling > Issue Type: Bug > Components: Repoinit > Reporter: Angela Schreiber > Assignee: Angela Schreiber > Priority: Major > Attachments: SLING-11160-initial-draft.patch > > Time Spent: 1h 40m > Remaining Estimate: 0h > > With SLING-9090 support for using _REMOVE *_ for all entries at a given path > or for a given principal has been implemented. > However as indicated in the same issue the intended usage of _REMOVE > some-thing-specific_ is not clear. > What is therefore missing with repo-init is the ability to remove a single > access control entry that matches > - prinicipal > - privileges > - allow-status > - single value restriction > - mv restrictions. > As far as I can see the biggest issue is the fact that REMOVE vs ALLOW/DENY > are mutually exclusive as the other params listed above can be extracted from > a given AclLine in combination with the set-ACL statement. > This could be fixed by adjusting the following parser method > {code} > AclLine privilegesLineOperation() : > {} > { > ( > <REMOVE> { return new AclLine(AclLine.Action.REMOVE); } > | ( <ALLOW> { return new AclLine(AclLine.Action.ALLOW); } ) > | ( <DENY> { return new AclLine(AclLine.Action.DENY); } ) > ) > } > {code} > such that > - REMOVE is optional, followed by > - ALLOW or DENY > The {{AclLine}} would then need to be slightly adjusted such that REMOVE can > be combined with either ALLOW or DENY. > Otherwise, I don't see how > {{AccessControlList.removeAccessControlEntry(AccessControlEntry)}} could be > implemented in org.apache.sling.jcr.repoinit for a single ACE. > Or maybe the intention was something different in the first place? > [~bdelacretaz], I would appreciate if you had time to comment on this. > cc: [~kpauls], [~cziegeler] -- This message was sent by Atlassian Jira (v8.20.1#820001)