jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Angela Schreiber <anch...@adobe.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/versi...
Date Wed, 20 Mar 2013 16:46:37 GMT
hi jukka

i like the idea of having read permission enforced on the node state
level and avoid the null checks as it is a similar approach we
are currently having by the treelocation concept that michael introduced
some time ago.

the only thing i keep struggling with is: i don't want to evaluate
read access for all parent items which most probably will not be
read within the lifespan of a session but rather limit permission
evaluation to those items that are actually being accessed... which
in our use case rather resembles a random access pattern plus
1 or 2 levels at a given tree location than a simple traversal.
in other words: in order to evaluate the permission at some location
in the hierarchy with our mainly path based permission model
we somehow need to be able to provide the hierarchy information
which as far as i saw so far was missing on the nodestate api.

that's the main piece that i was missing... otherwise your proposal
make sense to me.

kind regards

On 3/20/13 11:24 AM, Jukka Zitting wrote:
> 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

View raw message