[
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)
