Description
while trying to reproduce OAK-2412 i found that Node.getPrimaryType and Node.getMixinNodeTypes behave differently wrt Jackrabbit 2.x if the underlying JCR property is not accessible to the editing session.
While Jackrabbit 2.x directly reads the type information from the non-secured NodeState and only enforces a permission evaluation if the corresponding JCR properties are access, Oak obtains the type information through the JCR (or Oak API) which always secures the access to the underlying node state.
From a security point of view the Oak behavior looks somehow more consistent to me, but one could also argue that reading meta information associated with an Node by the means of regular Node-API calls should be accessible if the node itself can be read by the editing session.
From a backwards compatibility point of view, the Oak behavior is a clear break of compatibility which seems to cause issues with applications that relied to the Jackrabbit specific behavior.
As long as the default implementation doesn't provide means to easily grant read-access to a Node and it's Properties, we should probably fix the regression.
Attachments
Issue Links
- is related to
-
OAK-2412 Rep:glob in Access Control List Entry with empty value is not correcty handled
-
- Resolved
-
-
-
- Closed
-
-
-
- Closed
-
- is required by
-
-
- Closed
-