[
https://issues.apache.org/jira/browse/JCR-3492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13556330#comment-13556330
]
angela commented on JCR-3492:
-----------------------------
I just had a quick look: The problem applies for all write operations exposed
by VersionHistory interface; specifically it is caused by the following
permission check in the version history:
{code}
private void checkVersionManagementPermission() throws RepositoryException {
try {
sessionContext.getAccessManager().checkPermission(getPrimaryPath(),
Permission.VERSION_MNGMT);
} catch (ItemNotFoundException e) {
// ignore.
}
}
{code}
which doesn't check for jcr:versionManagement being granted on the versionable
node but rather on the version history node.
there are even some tests for VersionHistory#removeVersion that assert the
current behavior (AbstractVersionManagementTest#testRemoveVersion and variants).
while changing the permission check to
{code}
sessionContext.getAccessManager().checkPermission(getInternalVersionHistory().getVersionableId(),
Permission.VERSION_MNGMT);
{code}
seems to fix the reported problem in a regular situation, it will cause
inconsistencies for cases where the versionable node does not exist any
more (just the version archive is left... which can just be access by direct
path to the version history as well -> see JCR-2963).
so... i am be hesitating changing the current behavior.... opinions?
voila, a test case illustrating the issue:
{code}
public void testAddVersionLabel() throws RepositoryException,
NotExecutableException {
Node trn = getTestNode();
Node n = createVersionableNode(testRootNode);
String path = n.getPath();
JackrabbitAccessControlList tmpl = getPolicy(acMgr, path,
testUser.getPrincipal());
try {
tmpl.addEntry(testUser.getPrincipal(),
privilegesFromName(Privilege.JCR_VERSION_MANAGEMENT), true,
getRestrictions(superuser, path));
acMgr.setPolicy(tmpl.getPath(), tmpl);
superuser.save();
Node testNode = trn.getNode(nodeName1);
Version v = testNode.checkin();
testNode.checkout();
Version v2 = testNode.checkin();
testNode.checkout();
// -> VersionHistory.addVersionLabel must be allowed
VersionHistory history = testNode.getVersionHistory();
history.addVersionLabel(v.getName(), "testLabel", false);
history.addVersionLabel(v2.getName(), "testLabel", true);
VersionManager vMgr =
getTestSession().getWorkspace().getVersionManager();
history = vMgr.getVersionHistory(testNode.getPath());
history.addVersionLabel(v.getName(), "testLabel", true);
} finally {
// revert privilege modification (manually remove the ACE added)
AccessControlEntry[] entries = tmpl.getAccessControlEntries();
for (AccessControlEntry entry1 : entries) {
if (entry1.getPrincipal().equals(testUser.getPrincipal())) {
tmpl.removeAccessControlEntry(entry1);
}
}
acMgr.setPolicy(tmpl.getPath(), tmpl);
superuser.save();
}
}
{code}
> versionHistory.addVersionLabel() fails with AccessDeniedException even when
> user has proper permission
> ------------------------------------------------------------------------------------------------------
>
> Key: JCR-3492
> URL: https://issues.apache.org/jira/browse/JCR-3492
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-core, security, versioning
> Affects Versions: 2.5.2
> Reporter: Amit Gupta
> Priority: Critical
>
> If a user does not have access to version store node and following operation
> fails with access denied
> versionHistory.addVersionLabel(version.getName(), label, true);
> 16.01.2013 12:23:44.740 WARN [0:0:0:0:0:0:0:1 [1358319224592] GET
> /libs/dam/gui/content/assets/versioning/createversion.html HTTP/1.1]
> com.adobe.granite.asset.core.impl.AssetVersionManagerImpl Failed to add
> version label javax.jcr.AccessDeniedException: Access denied.
> at
> org.apache.jackrabbit.core.security.DefaultAccessManager.checkPermission(DefaultAccessManager.java:193)
> at
> org.apache.jackrabbit.core.version.VersionHistoryImpl.checkVersionManagementPermission(VersionHistoryImpl.java:311)
> at
> org.apache.jackrabbit.core.version.VersionHistoryImpl.addVersionLabel(VersionHistoryImpl.java:172)
> whereas the user have proper acl on the node that is being versioned. checkin
> and checkout operations are successful, it is just the addVersionlabel that
> fails.
--
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
