jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bart van der Schans <b.vandersch...@onehippo.com>
Subject Re: NodeStates and security (Re: svn commit: r1458234 - in /jackrabbit/oak/trunk: oak-core/src/main/java/org/apache/jackrabbit/oak/core/ oak-core/src/main/java/org/apache/jackrabbit/oak/kernel/ oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/version/ oak-core/src/main/java/o)
Date Wed, 20 Mar 2013 11:34:41 GMT
On Wed, Mar 20, 2013 at 11:24 AM, Jukka Zitting <jukka.zitting@gmail.com> wrote:
> The only complication there, as already discussed before, is the
> inability of the current NodeState interface to handle cases where a
> child node is readable even if its parent is not.

This is a quite problematic use-case.

Consider the a structure like:

And a user that is not allowed to read node C and has read/write
permissions on all other nodes. The view of that user would be two

Now the user tries to move node B below D, aka:

This would of course create a "circular" path and the save should fail
(in the sessions or on save?). But what kind of error should you get
without revealing the existence of node C?

This is the most trivial example, but it can get rather complicated
with multiple sessions and multiple "hidden" nodes and a mix of
operations. For this reason we require in our own access manager for
read access to a node that the user has also read access to all parent
nodes. I think it's a fair trade off of functionality versus code


View raw message