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] [Comment Edited] (OAK-3324) Evaluation with restriction is not consistent with parent ACLs
Date Fri, 04 Sep 2015 14:30:45 GMT

    [ https://issues.apache.org/jira/browse/OAK-3324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14730876#comment-14730876
] 

Tobias Bocanegra edited comment on OAK-3324 at 9/4/15 2:30 PM:
---------------------------------------------------------------

I think we need to define how the restrictions should work. do they work like virtual ACEs
wherever they match, or are only effective where they are defined, but activated if an item
matches them.

further we need to define, if they inherit the permissions down like normal ACEs.

for example, consider this test:

{noformat}
// allow rep:write          /testroot
// deny  jcr:modifyProperties /testroot/a  glob=*/c
{noformat}

this currently evaluates like this:

{noformat}
assertIsGranted(pp, testRoot, true , TEST_A_PATH, Permissions.MODIFY_PROPERTY);
assertIsGranted(pp, testRoot, true, TEST_B_PATH, Permissions.MODIFY_PROPERTY);
assertIsGranted(pp, testRoot, false, TEST_C_PATH, Permissions.MODIFY_PROPERTY);
assertIsGranted(pp, testRoot, true, TEST_D_PATH, Permissions.MODIFY_PROPERTY);
assertIsGranted(pp, testRoot, true, TEST_E_PATH, Permissions.MODIFY_PROPERTY);
{noformat}

so the D and E nodes are not affected by the restriction that is effective on C. If this is
the desired behavior, it should also work like this for REMOVE_NODE and ADD_NODE.

the same setup with REMOVE_NODE shows this behavior:
{noformat}
assertIsGranted(pp, testRoot, true, TEST_A_PATH, Permissions.REMOVE_NODE);
assertIsGranted(pp, testRoot, true, TEST_B_PATH, Permissions.REMOVE_NODE);
assertIsGranted(pp, testRoot, false, TEST_C_PATH, Permissions.REMOVE_NODE);
assertIsGranted(pp, testRoot, false, TEST_D_PATH, Permissions.REMOVE_NODE);
assertIsGranted(pp, testRoot, true, TEST_E_PATH, Permissions.REMOVE_NODE);
{noformat}

which is completely inconsistent.


was (Author: tripod):
I think we need to define how the restrictions should work. do they work like virtual ACEs
wherever they match, or are only effective where they are defined, but activated if an item
matches them.

further we need to define, if they inherit the permissions down like normal ACEs.

for example, consider this test:

{noformat}
// allow rep:write          /testroot
// deny  jcr:modifyProperties /testroot/a  glob=*/c
{noformat}

this currently evaluates like this:

{noformat}
assertIsGranted(pp, testRoot, true , TEST_A_PATH, Permissions.MODIFY_PROPERTY);
assertIsGranted(pp, testRoot, true, TEST_B_PATH, Permissions.MODIFY_PROPERTY);
assertIsGranted(pp, testRoot, false, TEST_C_PATH, Permissions.MODIFY_PROPERTY);
assertIsGranted(pp, testRoot, true, TEST_D_PATH, Permissions.MODIFY_PROPERTY);
assertIsGranted(pp, testRoot, true, TEST_E_PATH, Permissions.MODIFY_PROPERTY);
{noformat}

so the D and E nodes are not affected by the restriction that is effective on C. If this is
the desired behavior, it should also work like this for REMOVE_NODE and ADD_NODE.

> Evaluation with restriction is not consistent with parent ACLs
> --------------------------------------------------------------
>
>                 Key: OAK-3324
>                 URL: https://issues.apache.org/jira/browse/OAK-3324
>             Project: Jackrabbit Oak
>          Issue Type: Bug
>          Components: security
>    Affects Versions: 1.3.4
>            Reporter: Tobias Bocanegra
>            Assignee: Tobias Bocanegra
>
> consider the following ACL setup:
> {noformat}
> testuser allow rep:read,rep:write      /testroot
> testuser deny  jcr:removeNode /testroot/a  glob=*/c
> testuser allow jcr:removeNode /testroot/a  glob=*/b
> {noformat}
> now: {{hasPermission(/tesroot/a/b/c, jcr:removeNode) == false}} but the user is still
able to delete the node.
> * if we change the order of the ACEs with the restriction, it works (i.e. the user can't
delete)
> * if we use direct ACLs on the respective nodes, it works
> I think this is a bug...but I'm not sure if {{hasPermission}} is wrong, or the check
during node deletion.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message