[
https://issues.apache.org/jira/browse/OAK-3517?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14958554#comment-14958554
]
angela edited comment on OAK-3517 at 10/15/15 9:09 AM:
-------------------------------------------------------
[~Csaba Varga], confirming the issue you reported. attached you can find a
very simple unit-test illustrating the problem including the fix (as you
already pointed out to in the initial report).
was (Author: anchela):
[~Csaba Varga], confirming the issue you found. attached you can find a very
simple unit-test illustrating the problem including the fix (as you already
pointed out to in the initial report).
> Node.addNode(String, String) may check permissions 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
> Priority: Minor
> 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)
