jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nick Tuckett (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (JCR-3436) Access control issue accessing unsaved node changes inside a transaction
Date Wed, 03 Oct 2012 08:02:07 GMT

     [ 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

Mime
View raw message