[ https://issues.apache.org/jira/browse/SLING-9090?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17058572#comment-17058572 ]
Bertrand Delacretaz commented on SLING-9090: -------------------------------------------- It looks like the impact of REMOVE can be unclear indeed. Would the 3 scenarios mentioned at SLING-7147 make sense? Or shall we just implement REMOVE * with the first two rules mentioned there: * REMOVE * FOR <principal name> removes entries that match the given principals * REMOVE * ON <paths> removes all entries at the given paths and writes back an empty policy This would "clean up" things as a starting point after which the appropriate ACLs can be re-added. {quote}the docs do not not mention that remove is being converted to deny under the hood... {quote} Indeed and I think that's a bug, if there's no clarity on what REMOVE should do I would at least change it to a do-nothing operation and log info about that. > AclLine.Action.REMOVE and AclLine.Action.REMOVE_ALL not handled in jcr > implementation > ------------------------------------------------------------------------------------- > > Key: SLING-9090 > URL: https://issues.apache.org/jira/browse/SLING-9090 > Project: Sling > Issue Type: Bug > Components: Repoinit > Reporter: Angela Schreiber > Priority: Major > > [~bdelacretaz], while the documentation and the parser code provides the > ability to remove an individual or all access control entries, it seems the > JCR implementation doesn't actually support it. > using it may lead to odd side effects or failures.... so, i think either the > parser should remove the support for Action.REMOVE and Action.REMOVE_ALL or > the jcr implementation part should respect it... at the very minimum it > should spot any usage of it and fail the repo-init if there is no way to > implement it properly. -- This message was sent by Atlassian Jira (v8.3.4#803005)