jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "angela (JIRA)" <j...@apache.org>
Subject [jira] [Created] (JCR-2963) Separate versioning API operations from accessibility of the version store exposed under /jcr:system/jcr:versionStorage
Date Thu, 05 May 2011 16:29:03 GMT
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

View raw message