Shareable nodes and access control

[Ard Schrijvers <a....@onehippo.com>]

Hello,

>From the spec jsr-283 I cannot get my head around one thing:

* What is the expected behaviour of modifying child nodes of shared
nodes, when you are not allowed to read the child nodes of one of the
shared nodes (because of some access path constraint for example).

Another thing that I am curious about, though I have to look into the
code still, is how searching for shareable nodes with path constraints
& access work out.

 I assume it should work as:

1) Without path constraints, searches return me the 'principal'
location of shareable nodes.
2) With path constraints, I assume a hit is returned that matches the
path constraint, and thus might be not the 'principal' location
3) With access, and this is the tricky one as this is *not* known
during Lucene query time, it should return me a node that might be not
the 'principal' one because of I am not allowed to access the
principal one (how does this relate to the hit collapsing, which I
assume already happens during Lucene query for performance reasons)

Well, I admit I still have to dive into the code, but I was just
wondering how these case should be handled in general

thx for any feedback

Regards Ard

Re: Shareable nodes and access control

[Ard Schrijvers <a....@onehippo.com>]

Hello Toby,

On Tue, Jul 27, 2010 at 11:01 PM, Tobias Bocanegra
<to...@day.com> wrote:
> hi,
>
> On Mon, Jul 26, 2010 at 1:12 PM, Ard Schrijvers
> <a....@onehippo.com> wrote:
>> Hello,
>>
>> From the spec jsr-283 I cannot get my head around one thing:
>>
>> * What is the expected behaviour of modifying child nodes of shared
>> nodes, when you are not allowed to read the child nodes of one of the
>> shared nodes (because of some access path constraint for example).
> i'm not sure how exactly it is implemented currently, but for resource
> based access control, i think that only the primary ancestors inherit
> the ACLs.
> so the ACL of a shared set is the one of the primary node. for user
> centric access control, it's of course path based.

The ambiguity with the ACL based on the primary ancestor, is that
through the shared set, you could change a descendant shared node in a
complete different part of the tree, which you are not allowed to
read.. OTOH, perhaps it makes perfect sense: I assume it works the
same for symlinks

Thx Toby

Regards Ard

>
> regards, toby
>

Re: Shareable nodes and access control

[Tobias Bocanegra <to...@day.com>]

hi,

On Mon, Jul 26, 2010 at 1:12 PM, Ard Schrijvers
<a....@onehippo.com> wrote:
> Hello,
>
> From the spec jsr-283 I cannot get my head around one thing:
>
> * What is the expected behaviour of modifying child nodes of shared
> nodes, when you are not allowed to read the child nodes of one of the
> shared nodes (because of some access path constraint for example).
i'm not sure how exactly it is implemented currently, but for resource
based access control, i think that only the primary ancestors inherit
the ACLs.
so the ACL of a shared set is the one of the primary node. for user
centric access control, it's of course path based.

regards, toby

> Another thing that I am curious about, though I have to look into the
> code still, is how searching for shareable nodes with path constraints
> & access work out.
>
>  I assume it should work as:
>
> 1) Without path constraints, searches return me the 'principal'
> location of shareable nodes.
> 2) With path constraints, I assume a hit is returned that matches the
> path constraint, and thus might be not the 'principal' location
> 3) With access, and this is the tricky one as this is *not* known
> during Lucene query time, it should return me a node that might be not
> the 'principal' one because of I am not allowed to access the
> principal one (how does this relate to the hit collapsing, which I
> assume already happens during Lucene query for performance reasons)
>
> Well, I admit I still have to dive into the code, but I was just
> wondering how these case should be handled in general
>
> thx for any feedback
>
> Regards Ard
>