jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jukka Zitting <jukka.zitt...@gmail.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 12:11:42 GMT

On Wed, Mar 20, 2013 at 1:34 PM, Bart van der Schans
<b.vanderschans@onehippo.com> wrote:
> This is a quite problematic use-case.

Depends on your point of view. The way I see it, the scenario is
equivalent to a Unix directory with the execute bit set but the read
bit cleared.

> Consider the a structure like:
> /A/B/C/D
> 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
> "subtrees":
> /A/B
> /D

The Unix scenario, and the way it's currently implemented in
Jackrabbit and planned for Oak, is different. The user would be able
to access the following nodes:


The user can of course deduce the presence of node /A/B/C from the
above, but any attempt to directly read the node would result in an

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

With the above approach this would in any case fail, regardless of
access controls.


Jukka Zitting

View raw message