You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by "Nick Tuckett (JIRA)" <ji...@apache.org> on 2012/10/03 10:00:07 UTC

[jira] [Created] (JCR-3436) Access control issue accessing unsaved node changes inside a transaction

Nick Tuckett created JCR-3436:
---------------------------------

             Summary: 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


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

[jira] [Updated] (JCR-3436) Access control issue accessing unsaved node changes inside a transaction

Posted by "Nick Tuckett (JIRA)" <ji...@apache.org>.
     [ 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