jackrabbit-oak-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tobias Bocanegra (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (OAK-3351) Add ability to prioritise restriction to where it matches
Date Fri, 04 Sep 2015 20:23:46 GMT

    [ 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 

allow rep:read,rep:write /a
deny  jcr:removeNode     /a hasProperty=protect-me


> 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

View raw message