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)