[
https://issues.apache.org/jira/browse/JCR-3436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nick Tuckett updated JCR-3436:
------------------------------
Attachment: AclTransactionTest.java
JUnit test file that reproduces the issue.
> Access control issue accessing unsaved node changes inside a transaction
> ------------------------------------------------------------------------
>
> Key: JCR-3436
> URL: https://issues.apache.org/jira/browse/JCR-3436
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Affects Versions: 2.4.2
> Reporter: Nick Tuckett
> Attachments: AclTransactionTest.java
>
>
> I'm working with Jackrabbit 2.4.2 and have the following scenario:
> * Create a session for a non-admin user account.
> * Cast the session to an XAResource, generate a new transaction ID and start
> a transaction (like org.apache.jackrabbit.core.UserTransactionImpl).
> * Use the session to create a new node, record its identifier then set some
> properties and save the session.
> ** Make a further change to the node but do NOT save it
> ** Attempt to get the new node via its identifier.
> *** javax.jcr.ItemNotFoundException is thrown from inside
> org.apache.jackrabbit.core.security.authorization.acl.CompiledPermissionsImpl.canRead
> when it uses an ItemManager instance to get the new node.
> I have debugged through my code and the Jackrabbit code it calls, and can
> see the following:
> * My new node is present in the item cache for my session, which is retrieved
> ok by the getNodeByIdentifier() call.
> * The permissions check above tries to retrieve my node by id using a
> different (system) session in the DefaultAccessManager, which doesn't have my
> node in its cache. This attempts to read the node from the persistence layer
> as a result, which fails as the data won't be there because of the
> transaction.
> If I perform the same operation with an admin account, it works fine as the
> can-read check is short-circuited to always return true.
> The key seems to be to have an unsaved change on the new node which is being
> retrieved. This means the node's item state is
> ItemState.STATUS_EXISTING_MODIFIED, which causes ItemManager.canRead() to
> check with the access manager for read permission - leading to the exception
> described below.
> If there is no unsaved change on the new node, its state is
> ItemState.STATUS_NEW, which makes ItemManager.canRead() return true (default
> assumption for new nodes added by client code).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
