[
https://issues.apache.org/jira/browse/OAK-3517?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14958677#comment-14958677
]
angela commented on OAK-3517:
-----------------------------
uh... i wasn't aware that 1.3.8 was already cut as it still appeared in the
list of unreleased versions. obviously this issue will only be in 1.3.9
> Node.addNode(String, String) may check nt-mgt-permission against the wrong
> node
> -------------------------------------------------------------------------------
>
> Key: OAK-3517
> URL: https://issues.apache.org/jira/browse/OAK-3517
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: jcr
> Reporter: Csaba Varga
> Assignee: angela
> Fix For: 1.3.9
>
> Attachments: OAK-3517.patch, PermissionIssueDemo.java
>
>
> While I was troubleshooting an issue we're having in AEM 6.1, I've noticed an
> "impossible" access denied exception in the logs: the user had permission to
> add nodes under the node in question but still got an error.
> Some testing narrowed the issue down to a difference in behavior between the
> following two invocations:
> {{someNode.getNode("child").addNode("grandchild", "nt:unstructured");}}
> {{someNode.addNode("child/grandchild", "nt:unstructured");}}
> As far as I can tell, both should behave identically per the JCR spec, but
> the second one fails if the user doesn't have node type management permission
> to someNode, even if they have that permission to someNode/child.
> I believe the issue is in line 283 of
> [NodeImpl|https://svn.apache.org/repos/asf/jackrabbit/oak/trunk/oak-jcr/src/main/java/org/apache/jackrabbit/oak/jcr/session/NodeImpl.java]:
> it is checking permissions against dlg.getTree(), but it should really check
> against parent.getTree(), or if possible, the path of the node that's about
> to be created (so glob restrictions can be evaluated).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
