You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by "Thomas März (JIRA)" <ji...@apache.org> on 2012/06/28 18:29:44 UTC
[jira] [Created] (JCR-3364) Moving of nodes requires read access to
the whole tree
Thomas März created JCR-3364:
--------------------------------
Summary: Moving of nodes requires read access to the whole tree
Key: JCR-3364
URL: https://issues.apache.org/jira/browse/JCR-3364
Project: Jackrabbit Content Repository
Issue Type: Bug
Components: jackrabbit-core
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
[jira] [Updated] (JCR-3364) Moving of nodes requires read access to
the whole tree
Posted by "Thomas März (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-3364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Thomas März updated JCR-3364:
-----------------------------
Affects Version/s: 2.2.12
2.4.2
2.5
> Moving of nodes requires read access to the whole tree
> -------------------------------------------------------
>
> 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
[jira] [Commented] (JCR-3364) Moving of nodes requires read access
to all parent nodes of the destination node
Posted by "Bart van der Schans (JIRA)" <ji...@apache.org>.
[ 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
[jira] [Commented] (JCR-3364) Moving of nodes requires read access
to all parent nodes of the destination node
Posted by "Thomas März (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-3364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13406471#comment-13406471 ]
Thomas März commented on JCR-3364:
----------------------------------
Hello Bart,
wouldn't ItemManager#getItemData(ItemId itemId, Path path, boolean permissionCheck) with disabled permissionCheck help solving this problem?
Isn't this a use case the parameter permissionCheck should solve?
Best regards,
Thomas
By the way, here's part of the stacktrace:
{code}
javax.jcr.AccessDeniedException: cannot read item a0e6a28e-5546-41f0-b5e7-0b4815fc72b5
at org.apache.jackrabbit.core.ItemManager.createItemData(ItemManager.java:844)
at org.apache.jackrabbit.core.ItemManager.getItemData(ItemManager.java:391)
at org.apache.jackrabbit.core.ItemManager.getItem(ItemManager.java:328)
at org.apache.jackrabbit.core.ItemManager.getItem(ItemManager.java:622)
at org.apache.jackrabbit.core.NodeImpl$6.perform(NodeImpl.java:1710)
at org.apache.jackrabbit.core.NodeImpl$6.perform(NodeImpl.java:1705)
at org.apache.jackrabbit.core.session.SessionState.perform(SessionState.java:216)
at org.apache.jackrabbit.core.ItemImpl.perform(ItemImpl.java:91)
at org.apache.jackrabbit.core.NodeImpl.getParent(NodeImpl.java:1705)
at org.apache.jackrabbit.core.SessionMoveOperation.createTransientParentStates(SessionMoveOperation.java:213)
at org.apache.jackrabbit.core.SessionMoveOperation.perform(SessionMoveOperation.java:195)
at org.apache.jackrabbit.core.session.SessionState.perform(SessionState.java:216)
at org.apache.jackrabbit.core.SessionImpl.perform(SessionImpl.java:361)
at org.apache.jackrabbit.core.SessionImpl.move(SessionImpl.java:869)
{code}
> 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
[jira] [Updated] (JCR-3364) Moving of nodes requires read access to
all parent nodes of the destination node
Posted by "Bart van der Schans (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-3364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Bart van der Schans updated JCR-3364:
-------------------------------------
Summary: Moving of nodes requires read access to all parent nodes of the destination node (was: Moving of nodes requires read access to the whole tree )
> 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
[jira] [Commented] (JCR-3364) Moving of nodes requires read access
to the whole tree
Posted by "Bart van der Schans (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-3364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13406394#comment-13406394 ]
Bart van der Schans commented on JCR-3364:
------------------------------------------
Hi Thomas,
This might be a bit tricky. The only way to prevent the creation of cyclic paths (that I can see) is that all parent nodes of the target are pulled in the transient session of the user. For example in your example:
- /a/aa
- /b
sess1:
move /a to /b
results in:
- /b/a/aa
sess2:
move b to /a/aa
results in:
- /a/aa/b
sess1.save()
sess2.save() <- should fail, because that would create a cycle (parent of a is no longer root but /b)
The problem is that the second session cannot "check" this since if it has no read access to node a. So (at least in the current implementation) you need read access to all parent nodes of the target.
I suspect this is just one of the problems with not being able to read the parent nodes. I haven't really tried it, but item.getPath() should fail as well if you can't read all parent nodes?
> Moving of nodes requires read access to the whole tree
> -------------------------------------------------------
>
> 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