[
https://issues.apache.org/jira/browse/OAK-1115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13804260#comment-13804260
]
Jukka Zitting commented on OAK-1115:
------------------------------------
bq. well, the last time we discussed this, you said that it's seems better to
just enforce the remove permission for the remove target, didn't you?
Indeed I did. :-) The rationale was the interpretation that the permission to
remove a node would implicitly apply to the entire subtree below that node,
regardless of what other permissions are present.
If we do apply 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.
If we don't (case B), then we need to evaluate the remove permission on all
items within a removed (or moved) subtree. Otherwise a move permission
effectively grants full permissions over a subtree, as a client could first
move a tree to a temporary location under which it has full control, do
whatever changes it wants, and then move the modified subtree to the real
target location.
bq. an example: if you don't have permissions to read/edit AC content in a
given subtree but you are allowed to remove the root of that subtree, you could
remove that tree in jr2 irrespective of any kind of ac content being present in
the subtree...
Right. That's basically in line with case A above.
bq. example 2: a user that is not allowed to execute version operations but is
a allowed to remove a node should IMO be able to do so, although removing the
version related protected properties would not be allowed due to lack of the
corresponding version-mgt permission.
Right. I don't think it makes sense to apply protected item checks when the
entire node is being removed.
> 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)
