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 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 10:24:29 GMT
Hi,

On Tue, Mar 19, 2013 at 5:09 PM, Marcel Reutegger <mreutegg@adobe.com> wrote:
> AFAIU, NodeState was specifically designed to not require a path.

Indeed. The main rationale for the design is to avoid the cost of
having to support things like:

    assert state.getChildNode("foo").getName().equals("foo");

That seems like a simple thing, but prevents optimizations like the
EmptyNodeState or the ability of the SegmentMK to reuse existing
content to avoid duplicate copies of the same data. Thus I'd be
strongly against a proposal to introduce a method like
NodeState.getPath().

However, the design is also explicitly designed so that a particular
NodeState implementation *can* keep track of the path by recording all
the child node names used in successive getChildNode() calls until the
target node has been reached. This is what for example the
KernelNodeState does and also what we could do if we pushed (read)
access checks below the NodeState interface.

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.

To address that case I was thinking that we could revise the
getChildNode() contract to *always* return a new NodeState even if the
named child node did not exist. Coupled with something like a new
NodeState.exists() method (that would replace the current null checks
on getChildNode() return values) this would allow us to access nodes
down the hierarchy even if their parents don't "exist" for the current
user.

For example, to access a node like /foo/bar where the parent node /foo
is not accessible, we'd have:

    NodeState root = ...;
    NodeState foo = root.getChildNode("foo");
    NodeState bar = foo.getChildNode("bar"); // no null checks needed!

The existence of these nodes would then show up as:

    assert !foo.exists();
    assert bar.exists();

A nice benefit of such a design would be that the difference between a
node not existing at all or it being read-protected is entirely hidden
from higher levels, so it'll be harder to accidentally leak
information about the presence of a particular node.

BR,

Jukka Zitting

Mime
View raw message