[
https://issues.apache.org/jira/browse/OAK-3351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14731360#comment-14731360
]
Tobias Bocanegra commented on OAK-3351:
---------------------------------------
see work in OAK-3324. The ACEs with restrictions don't inherit the permissions.
so the scenario above can not simple be solved with a
{noformat}
allow rep:read,rep:write /a
deny jcr:removeNode /a hasProperty=protect-me
{noformat}
rule.
> Add ability to prioritise restriction to where it matches
> ---------------------------------------------------------
>
> Key: OAK-3351
> URL: https://issues.apache.org/jira/browse/OAK-3351
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: security
> Reporter: Tobias Bocanegra
> Assignee: Tobias Bocanegra
> Priority: Minor
>
> Consider the following use case:
> A node, and not its subtree, should be protected from removal, if it contains
> a defined property. a custom jcr:protected so to speak.
> The idea is to create a restriction provider that enables the ACE when the
> property is set. for example:
> {noformat}
> allow rep:read,rep:write /a
> deny jcr:removeNode /a hasProperty=protect-me
> allow jcr:removeNode /a hasProperty=!protect-me
> {noformat}
> the _allow_ is needed so that the child nodes of a protected node are still
> removable, if they are not protected themselves.
> The problem is now, that the ACE does not apply where it matches, but where
> it is defined.
> so assume we have a node {{/a/b/c}} protected. the ACE in {{/a}} would then
> match the node, but also the parent {{/a/b}} if it is not protected would
> match the allow rule, since the REMOVE_NODE is a permission that also needs
> to check the REMOVE_CHILDNODES privilege on the parent. And since the allow
> ACE is after the deny one, it wins.
> So either the parent-check needs to be delayed to a later stage, or we can
> define that an ACE with restriction can be sorted in a way that it applies
> where it matches, so that it looks like the ACE was specified on {{/a/b/c}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
