jackrabbit-oak-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "angela (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (OAK-2933) AccessDenied when modifying transiently moved item with too many ACEs
Date Tue, 02 Jun 2015 14:16:29 GMT

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

angela edited comment on OAK-2933 at 6/2/15 2:16 PM:
-----------------------------------------------------

in order to reproduce the behavior i set the eager-cache-size to 0 in {{PermissionEntryProviderImpl}}
and run {{SessionMoveTest}}. Looking at the tests that failed in this case and debugging the
permission evaluation I found that {{MoveAwarePermissionValidator#visibleValidator}} is effectively
generating empty immutable trees and that are not backed by an {{NodeState}} because I forgot
to reset the parent object while traversing from the {{beforeRoot}}. Consequently the {{TreePermission}}
objects didn't have a tree associated that contains any data and would therefore just look
at the permission present at the root (unless there is a cache entry).

[~tripod], may I kindly ask you to look at the proposed patch. I run the complete build with
both cache-size set to 0 and the default value. So, that seems to be at least one piece in
the problem... at least a obvious bug that seems trivial to fix.


was (Author: anchela):
in order to reproduce the behavior i set the eager-cache-size to 0 in {{PermissionEntryProviderImpl}}
and run {{SessionMoveTest}}. Looking at the tests that failed in this case and debugging the
permission evaluation I found that {{MoveAwarePermissionValidator#visibleValidator}} is effectively
generating empty immutable trees and that are not backed by an {{NodeState}} because I forgot
to reset the parent object while traversing from the {{beforeRoot}}. Consequently the {{TreePermission}}
objects didn't have a tree associated that contains any data and would therefore just look
at the permission present at the root.

[~tripod], may I kindly ask you to look at the proposed patch. I run the complete build with
both cache-size set to 0 and the default value. So, that seems to be at least one piece in
the problem... at least a obvious bug that seems trivial to fix.

> AccessDenied when modifying transiently moved item with too many ACEs
> ---------------------------------------------------------------------
>
>                 Key: OAK-2933
>                 URL: https://issues.apache.org/jira/browse/OAK-2933
>             Project: Jackrabbit Oak
>          Issue Type: Bug
>          Components: security
>    Affects Versions: 1.0.13
>            Reporter: Tobias Bocanegra
>            Assignee: angela
>         Attachments: OAK-2933.patch
>
>
> If at least the following preconditions are fulfilled, saving a moved item fails with
access denied:
> 1. there are more PermissionEntries in the PermissionEntryCache than the configured EagerCacheSize
> 2. an node is moved to a location where the user has write access through a group membership
> 3. a property is added to the transiently moved item
> For example:
> 1. set the *eagerCacheSize* to '0'
> 2. create new group *testgroup* and user *testuser*
> 3. make *testuser* member of *testgroup*
> 4. create nodes {{/testroot/a}} and {{/testroot/a/b}} and {{/testroot/a/c}}
> 5. allow *testgroup* {{rep:write}} on {{/testroot/a}}
> 6. as *testuser* create {{/testroot/a/b/item}} (to verify that the user has write access)
> 7. as *testuser* move {{/testroot/a/b/item}} to {{/testroot/a/c/item}}
> 8. {{save()}} -> works
> 9. as *testuser* move {{/testroot/a/c/item}} back to {{/testroot/a/b/item}} AND add new
property to the transient {{/testroot/a/b/item}}
> 10. {{save()}} -> access denied



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

Mime
View raw message