[
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)
