Different Permissions on the Same Node

Multiple roles can have different permissions on the same node. Some interactions between roles may be unexpected. For example, if you have a document with two nodes <foo> and <bar>. The <bar> node is a child of the <foo> node.

<foo>
  <bar>

You have two roles; role1 with both read and update permissions on the <foo> node, and role2 with read permissions on the <bar> node:

<foo>, ("role1", "read"), ("role1", "node-update")
<bar>, ("role2", "read")

The protected paths for this document would look like this:

sec:protect-path("//foo", (), (
xdmp:permission("els-role-1", "read"),("role1", "node-update")) 

sec:protect-path("//foo/bar", (), (
xdmp:permission("role2", "read"))

With these protected paths, role1 cannot read the <bar> node. But because role1 has update permissions on the parent node (<foo>), role1 can overwrite the <bar> node, even though it cannot read it.

To prevent this, add node-update permissions to the <bar> node. The permissions would now look like this:

<foo>, ("role1", "read"), ("role1", "node-update")
<bar>, ("role2", "read"), ("role2", "node-update")

The presence of the “node-update” permission on the <bar> node prevents role1 from being able to update and overwrite the <bar> node (the child node of the <foo> node).

This happens because node permissions are checked separately; first there’s a check for protected paths for read. Then there is a check for protected paths for update. If no update is found for /foo/bar, then role1 is allowed to update <bar>. If there is a protected path for updating <bar>, then role1 is not allowed to update <bar>.