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 13:56:30 GMT

On Wed, Mar 20, 2013 at 2:52 PM, Bart van der Schans
<b.vanderschans@onehippo.com> wrote:
> 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?

Yes. On the other hand you could argue that making a node at /foo/bar
readable to someone implicitly grants them knowledge about the
presence of a node at /foo, even if they don't necessarily have direct
read access to that node. A call like session.getNode("/foo") could
still fail.

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

The problem can be detected even by just looking at the paths being
moved. The failure of move("/A/B", "/A/B/C/D") should be fairly

> 3. allow implicit read access to all parent nodes (for example by path
> discovery), but not allow read permissions to its' properties

I'd rather call this implicit execute (or traversal) access instead of
read access, since a call like session.getNode("/foo") on a
non-readable parent should still fail. Otherwise a read-access check
on a node might potentially have to look through the entire subtree
for a readable descendant.


Jukka Zitting

View raw message