Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jackrabbit.apache.org
Date: Thu, 5 May 2011 16:29:03 +0000 (UTC)
From: "angela (JIRA)" <jira@apache.org>
To: dev@jackrabbit.apache.org
Message-ID: 
 <293590675.25121.1304612943212.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Created] (JCR-2963) Separate versioning API operations from
 accessibility of the version store exposed under
 /jcr:system/jcr:versionStorage
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

Separate versioning API operations from accessibility of the version store exposed under /jcr:system/jcr:versionStorage
-----------------------------------------------------------------------------------------------------------------------

                 Key: JCR-2963
                 URL: https://issues.apache.org/jira/browse/JCR-2963
             Project: Jackrabbit Content Repository
          Issue Type: Bug
          Components: jackrabbit-core, security, versioning
            Reporter: angela


this issue is known (at least) since the early days of jsr 283 implementation but unfortunately never made it into jira...

jsr 283 defines that "jcr:versionManagement: The privilege to perform versioning operations on a node" which - as far as i know is consistently enforced in jackrabbit-core. similarly the specification mandates that "If a repository supports full versioning, then it must expose the version storage at 
/jcr:system/jcr:versionStorage", which is defined to be a write protected area that is shared between all workspaces of a repository. however, the specification doesn't define the accessibility of the version storage by means of reading.

accessibility of the version storage:
in jackrabbit-core the accessibility of the tree present underneath jcr:system is controlled by regular read permissions such as defined on other nodes based on the security configuration of the repository and the workspace.

execution of versioning operations:
currently successful execution of versioning API operations (both reading and writing) depends on the accessibility of the version storage. from my point of view this is problematic it is not feasible to limit read permissions to those parts of the version storage that are - outside of the version storage - accessible to the reading/editing session. this basically implies that some being allowed to execute version operations and read versions must be allowed to read the complete version store. this will allow that session to be informed about versions of nodes that he/she might not be allowed to access otherwise.

in order to address this issue, we should consider/evaluate the following:
- execution of API operations should be separated from read-access to the version storage
- access to jcr:system should be restricted
- alternatively we might find a way to evaluate the readability of version content based on the accessibility of the corresponding node.
- traversing the node hierarchy starting from a version/versionhistory node and any other item located in the version storage should be restricted accordingly.


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira