From dev-return-36386-apmail-jackrabbit-dev-archive=jackrabbit.apache.org@jackrabbit.apache.org Wed Oct 3 08:02:10 2012 Return-Path: X-Original-To: apmail-jackrabbit-dev-archive@www.apache.org Delivered-To: apmail-jackrabbit-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 734D4D1B1 for ; Wed, 3 Oct 2012 08:02:10 +0000 (UTC) Received: (qmail 27278 invoked by uid 500); 3 Oct 2012 08:02:09 -0000 Delivered-To: apmail-jackrabbit-dev-archive@jackrabbit.apache.org Received: (qmail 27211 invoked by uid 500); 3 Oct 2012 08:02:08 -0000 Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@jackrabbit.apache.org Delivered-To: mailing list dev@jackrabbit.apache.org Received: (qmail 27188 invoked by uid 99); 3 Oct 2012 08:02:07 -0000 Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 03 Oct 2012 08:02:07 +0000 Date: Wed, 3 Oct 2012 19:02:07 +1100 (NCT) From: "Nick Tuckett (JIRA)" To: dev@jackrabbit.apache.org Message-ID: <1032547505.158184.1349251327829.JavaMail.jiratomcat@arcas> In-Reply-To: <1447465014.158183.1349251207665.JavaMail.jiratomcat@arcas> Subject: [jira] [Updated] (JCR-3436) Access control issue accessing unsaved node changes inside a transaction MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ 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