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