On Wed, Mar 20, 2013 at 1:11 PM, Jukka Zitting <[email protected]> wrote: > Hi, > > On Wed, Mar 20, 2013 at 1:34 PM, Bart van der Schans > <[email protected]> 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
