[
https://issues.apache.org/jira/browse/JCR-3492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13557034#comment-13557034
]
angela commented on JCR-3492:
-----------------------------
> checkin/checkout also modify the node that is checked in/out. so the user
> needs at least write permission on that node.
according to my reading of JSR 283 this is not true and only
jcr:versionManagement privilege is required in order to
modify the protected version items. for jcr:isCheckedOut et al. it's straight
forward to check the privilege on the
versionable node.
as stated in JCR-2963 we have a problem as soon as we want to enforce
jcr:versionManagement privilege on the
the items that are located in the version storage. the workspace argument is
not relevant IMO as in a given
jcr workspace the versionable item is clearly identifiable and it's perfectly
legal to have different permissions
in different workspaces.
since the current situation where access to the version store can only be
turned on/off in globo poses a security
problem, i have the impression binding version store permissions to the
permissions of the versionable node
would be favorable... only that we have to find a solution for the 'lost'
version content whose versionable node
has been removed... if we postpone that to OAK anyway i would defer the
resolution of this bug as well.
-> adding link to JCR-2963
> 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
