[
https://issues.apache.org/jira/browse/OAK-5947?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15936027#comment-15936027
]
angela edited comment on OAK-5947 at 4/27/17 9:22 AM:
------------------------------------------------------
As far as the {{AccessDeniedException}} is concerned this actually seems to be
a bug: while the {{AccessControlManager}} checks for read/modify-access-control
being granted on the {{null}} path upon get/set of policies, the subsequent
code writing down the new/modified {{rep:repoPolicy}} relies on the regular
permission evaluation, which doesn't treat the {{rep:repoPolicy}} node
specially and thus evaluates permissions of the root node instead of looking at
the permission of the {{null}} code. The actually issue is not located in the
{{SecureNodeBuilder}}, which must not know anything about a given authorization
model but rather in the {{TreePermissions}} implementation of the default
model. that one identifies the subtree defined by {{rep:repoPolicy}} as access
control content but doesn't handle it as repo-level access control.
I added a modified (and enhanced) test-case in the oak-core module at revision
1788080 illustrating the checks and expected exception raised by
{{AccessControlManagerImpl}} (see above) as well as the bug. The latter is
currently marked ignored.
was (Author: anchela):
As far as the {{AccessDeniedException}} is concerned this actually seems to be
a bug: while the {{AccessControlManager}} checks for read/modify-access-control
being granted on the {{null}} path upon get/set of policies, the subsequent
code writing down the new/modified {{rep:repoPolicy}} relies on the regular
permission evaluation, which doesn't treat the {{rep:repoPolicy}} node
specially and thus evaluates permissions of the root node instead of looking at
the permission of the {{null}} code. The actually issue is not located in the
{{SecureNodeBuilder}}, which must not know anything about a given authorization
model but rather in the {{TreePermissions}} implementation of the default
model. that one identifies the subtree defined by {{rep:repoPolicy}}} as access
control content but doesn't handle it as repo-level access control.
I added a modified (and enhanced) test-case in the oak-core module at revision
1788080 illustrating the checks and expected exception raised by
{{AccessControlManagerImpl}} (see above) as well as the bug. The latter is
currently marked ignored.
> Allowing non-admin user to set repository permissions fails
> -----------------------------------------------------------
>
> Key: OAK-5947
> URL: https://issues.apache.org/jira/browse/OAK-5947
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
> Affects Versions: 1.0, 1.2, 1.4.0, 1.6.0
> Reporter: Julian Sedding
> Assignee: angela
> Fix For: 1.8
>
> Attachments: SetRepoPolicyTest.patch
>
>
> Given a user principal {{testUser}} is granted {{jcr:readAccessControl}} and
> {{jcr:modifyAccessControl}} on the repository ({{rep:repoPolicy}}), I would
> expect that this user can e.g. allow {{everyone}} the
> {{jcr:namespaceManagement}} permission on the repository.
> Currently this fails with the following exception:
> {noformat}
> javax.jcr.PathNotFoundException: No tree at null
> at
> org.apache.jackrabbit.oak.spi.security.authorization.accesscontrol.AbstractAccessControlManager.getTree(AbstractAccessControlManager.java:163)
> at
> org.apache.jackrabbit.oak.security.authorization.accesscontrol.AccessControlManagerImpl.getApplicablePolicies(AccessControlManagerImpl.java:184)
> at
> org.apache.jackrabbit.oak.jcr.delegate.AccessControlManagerDelegator$7.perform(AccessControlManagerDelegator.java:121)
> at
> org.apache.jackrabbit.oak.jcr.delegate.AccessControlManagerDelegator$7.perform(AccessControlManagerDelegator.java:117)
> at
> org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.perform(SessionDelegate.java:208)
> at
> org.apache.jackrabbit.oak.jcr.delegate.AccessControlManagerDelegator.getApplicablePolicies(AccessControlManagerDelegator.java:117)
> at
> org.apache.jackrabbit.oak.jcr.delegate.JackrabbitAccessControlManagerDelegator.getApplicablePolicies(JackrabbitAccessControlManagerDelegator.java:147)
> at
> org.apache.jackrabbit.commons.jackrabbit.authorization.AccessControlUtils.getAccessControlList(AccessControlUtils.java:128)
> at
> org.apache.jackrabbit.oak.jcr.SetRepoPolicyPermissionsTest.setRepositoryPermissions(SetRepoPolicyPermissionsTest.java:85)
> ....
> {noformat}
> or after granting {{jcr:read}} on {{/}}:
> {noformat}
> javax.jcr.AccessDeniedException
> at org.apache.jackrabbit.oak.util.NodeUtil.addChild(NodeUtil.java:113)
> at
> org.apache.jackrabbit.oak.security.authorization.accesscontrol.AccessControlManagerImpl.setNodeBasedAcl(AccessControlManagerImpl.java:289)
> at
> org.apache.jackrabbit.oak.security.authorization.accesscontrol.AccessControlManagerImpl.setPolicy(AccessControlManagerImpl.java:220)
> at
> org.apache.jackrabbit.oak.jcr.delegate.AccessControlManagerDelegator$8.performVoid(AccessControlManagerDelegator.java:132)
> at
> org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.performVoid(SessionDelegate.java:274)
> at
> org.apache.jackrabbit.oak.jcr.delegate.AccessControlManagerDelegator.setPolicy(AccessControlManagerDelegator.java:129)
> at
> org.apache.jackrabbit.oak.jcr.delegate.JackrabbitAccessControlManagerDelegator.setPolicy(JackrabbitAccessControlManagerDelegator.java:152)
> at
> org.apache.jackrabbit.oak.jcr.SetRepoPolicyPermissionsTest.setRepositoryPermissions(SetRepoPolicyPermissionsTest.java:90)
> ....
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
