jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bart van der Schans (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (JCR-3364) Moving of nodes requires read access to all parent nodes of the destination node
Date Thu, 05 Jul 2012 11:11:34 GMT

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

Bart van der Schans commented on JCR-3364:
------------------------------------------

Hi Thomas,

The problem is that in the example I gave both session have a different hierarchy in their
transient sessions. Before there is any save/sync, both views are "correct".

Consider when the paths are a bit deeper:

- /a1/a2/aa 
- /b1/b2/ 

sess1: 
move a2 to /b1/b2 
results in the transient view of sess1: 
- /b1/b2/a2/aa
- /a1

sess2: 
move b1 to /a1/a2/aa 
results in the transient view of sess2: 
- /a1/a2/aa/b1/b2
- /

At this point sess1 has pulled b2 in its transient state since it's modiefied, but (without
my previous fix) b1 is never read by sess1 and not part of the transient state.

Now consider that sess2 does a save. There is nothing that prevents this save and the new
persistent hierarchy is sess2's view. At this point the parent of b1 is node aa.

Now sess1 does a getPath() on node "aa". This results in fetching the parent nodes for finding
out the path and now it's broken: aa > a2 > b2 > b1 (fetch from the shared/persistent
layer) > aa > a2 > b2 .... etc. etc. and a loop is created. Of course if you would
save this you would only persist the problem.

So in my opinion, moving a node to a new target means that the session needs to create it's
own transient view of the hierarchy of the target location. 

The problem you ran into is that you can't read a parent node. In the example about that would
be node b1 for sess1. I'm not sure if we can create a "hidden" transient state for the b1
node by setting the permission check to false in sess1. It might just popup somewhere in a
cache.

Can you check in your use case what actually happens if you create a quick hack so that the
createTransientParentStates method somehow calls the createItemData with the permission check
set to false?

Bart



                
> Moving of nodes requires read access to all parent nodes of the destination node
> --------------------------------------------------------------------------------
>
>                 Key: JCR-3364
>                 URL: https://issues.apache.org/jira/browse/JCR-3364
>             Project: Jackrabbit Content Repository
>          Issue Type: Bug
>          Components: jackrabbit-core
>    Affects Versions: 2.2.12, 2.4.2, 2.5
>            Reporter: Thomas März
>
> Before JCR-3291 was fixed, Session#move(String, String) could move nodes without having
read-access to the whole tree.
> - Deny jcr:read on /home and grant jcr:all on /home/users/usera to usera
> - Move nodes from /home/users/usera/from to /home/users/usera/to with usera's session
> - AccessDeniedException is thrown
> http://article.gmane.org/gmane.comp.apache.jackrabbit.user/18892

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

       

Mime
View raw message