jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcel Reutegger <mreut...@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/v...
Date Thu, 21 Mar 2013 13:02:59 GMT

I don't mean to disrupt your conversation about moving permission
evaluation further down the stack, but I still wanted to mention
that my initial understanding of the issue was actually different.
this may be a misunderstanding on my side, though I still
would like to hear from others what they think.

so, here's how I understood the motivation so far and what
I thought a solution would look like:

Permission evaluation is changed in a way that it does not use
the OAK API anymore, but rather operates on the NodeState
API. E.g. Angela earlier mentioned she'd like to have Tree.equals()
as is available on NodeState. Redesigning the evaluation to
work on NodeStates would have solved this problem.

Do we really understand well enough what the consequences
are moving permission evaluation even further down? I.e.
*below* the NodeState API? So far I considered this API
a low level storage interface, which is not aware of users.


> -----Original Message-----
> From: Jukka Zitting [mailto:jukka.zitting@gmail.com]
> Sent: Donnerstag, 21. März 2013 08:57
> To: Oak devs
> 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/v...
> Hi,
> On Wed, Mar 20, 2013 at 6:46 PM, Angela Schreiber <anchela@adobe.com>
> wrote:
> > the only thing i keep struggling with is: i don't want to evaluate
> > read access for all parent items
> There shouldn't be a need for doing that.
> Since the proposed getChildNode() calls would never return null, there
> won't be a need to perform access control checks on that method (the
> return value gives out no information about the presence, absense or
> accessibility of a node). The access check is only needed for the
> exists() and other NodeState methods that get called if a node is
> actually being read instead of just traversed.
> For example, accessing a path like the mentioned "/foo/bar", would
> ultimately boil down to something like the following sequence of
> calls:
>     NodeState root = ...;
>     NodeState foo = root.getChildNode("foo"); // no access check
>     NodeState bar = foo.getChildNode("bar"); // no access check
>     if (bar.exists()) { // access check performed here
>         return new Node(bar);
>     } else {
>         throw new NotFoundException();
>     }
> BR,
> Jukka Zitting

View raw message