Mailing-List: contact oak-dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: oak-dev@jackrabbit.apache.org
Received-SPF: pass (athena.apache.org: domain of b.vanderschans@1hippo.com
 designates 64.18.2.18 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAOFYJNZJQ=QoT-eEZ4=_XG72ZPCV8kLSTNAFY2UDTjkrtxijLA@mail.gmail.com>
References: 
 <CAOFYJNZvpdvgSuHV4FOBSDEMA-AjuGPNAyqvu-7akPj3KnTjCQ@mail.gmail.com>
 <CAAOnkMujGK_Nm8=0KNJ-nieGPOLJqhz5mCrrBGdnvyQ7WUSzuw@mail.gmail.com>
 <CAOFYJNZJQ=QoT-eEZ4=_XG72ZPCV8kLSTNAFY2UDTjkrtxijLA@mail.gmail.com>
From: Bart van der Schans <b.vanderschans@onehippo.com>
Date: Wed, 20 Mar 2013 13:52:52 +0100
Message-ID: 
 <CAAOnkMse3JADYP7pWCBW-+-DcB0f+nJHeHTXuaiGGsgxtNwLMA@mail.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)
To: oak-dev@jackrabbit.apache.org
Content-Type: text/plain; charset=UTF-8

On Wed, Mar 20, 2013 at 1:11 PM, Jukka Zitting <jukka.zitting@gmail.com> wrote:
> Hi,
>
> 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.

I don't think there is currently an equivalent of that permission set
for JCR. Of course we can introduce it and if we want to go the "unix
way" of permissions we might also want to consider (some of) the
extended attributes features.

>> 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:
>
>     /A
>     /A/B
>     /A/B/C/D
>
> 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
> error.

Isn't the idea in jcr that if you are not allowed to read a node that
you shouldn't be able to to deduce it's existence? For example you get
an itemnotfoundexception if you try to access a node to which you
don't have read permissions. If you allow the user to see the full
path you implicitly grant read permissions to the node (but maybe not
it's children or properties)

>> 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.

Yes of course. But if you can't read/see the intermediary node it's
hard to detect this case in the session itself. The save will still
fail of course although the user might not have a clue why.

So basically we have a few implementation choices here for this case:
1. introduce permissions to mimic the unix behavior of "+x -rw" (which
would also could allow for -xrw and would disallow reads on child
nodes as well)
2. require read access to all parent nodes to allow read access to a node
3. allow implicit read access to all parent nodes (for example by path
discovery), but not allow read permissions to its' properties
4. don't allow path discovery or "deducing" that the non readable node exist.

Regards,
Bart