You are viewing a plain text version of this content. The canonical link for it is here.
Posted to oak-issues@jackrabbit.apache.org by "Tobias Bocanegra (JIRA)" <ji...@apache.org> on 2015/09/04 14:11:45 UTC
[jira] [Created] (OAK-3351) Add ability to prioritise restriction
to where it matches
Tobias Bocanegra created OAK-3351:
-------------------------------------
Summary: 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
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)