[
https://issues.apache.org/jira/browse/OAK-1115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13805125#comment-13805125
]
angela commented on OAK-1115:
-----------------------------
{quote}
that rationale here (case A), then the removal of the child node within the
moved subtree isn't a problem as the session in any case had the permission to
remove it.
{quote}
i tend to disagree as there might be separate permissions that prevent you from
removing a particular subtree while you might be allowed to remove the entire
tree and i would still consider this 2 different operations if you move a tree
and the remove a subtree... but probably this rather an reason for handling the
move separately. if we don't but rather treat it as removal without we will
most certainly run into backwards compatibility issues.
the same also applies to the add that is associated with the move operation: if
the moved tree contains content (e.g. ac content) that was otherwise not
allowed to be added for a given session the move will fail though it would have
worked in jackrabbit 2.x.
> Remove of Subtree after Move is not subjected to permission validation
> ----------------------------------------------------------------------
>
> Key: OAK-1115
> URL: https://issues.apache.org/jira/browse/OAK-1115
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
> Reporter: angela
> Assignee: angela
> Priority: Critical
>
> the following test passes in Jackrabbit-Core but fails in OAK:
> {code}
> @Test
> public void testMoveRemoveSubTree() throws Exception {
> superuser.getNode(childNPath).addNode(nodeName3);
> superuser.save();
> /* allow READ/WRITE privilege for testUser at 'path' */
> givePrivileges(path, privilegesFromNames(new String[]
> {Privilege.JCR_READ, "rep:write"}), Collections.<String, Value>emptyMap());
> /* deny READ/REMOVE property privileges at subtree. */
> withdrawPrivileges(path, privilegesFromNames(new String[]
> {Privilege.JCR_REMOVE_NODE}), Collections.singletonMap("rep:glob",
> superuser.getValueFactory().createValue("*/"+nodeName3)));
> Session testSession = getTestSession();
> assertTrue(testSession.nodeExists(childNPath));
> assertTrue(testSession.hasPermission(childNPath,
> Session.ACTION_REMOVE));
> assertTrue(testSession.hasPermission(childNPath2,
> Session.ACTION_ADD_NODE));
> testSession.move(childNPath, childNPath2 + "/dest");
> Node dest = testSession.getNode(childNPath2 + "/dest");
> dest.getNode(nodeName3).remove();
> try {
> testSession.save();
> fail("Removing child node must be denied.");
> } catch (AccessDeniedException e) {
> // success
> }
> }
> {code}
> this is a critical security issue as it moving around the parent is
> sufficient in order to be able to remove a node that was otherwise not
> removable due to limited permissions.
> Afaik this behavior is caused by a limitation in the Diff process which
> doesn't allow to identify the move and thus makes it impossible to find out
> if that the subtree has been removed.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
