jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Angela Schreiber <anch...@adobe.com>
Subject Re: ACLs, GlobPattern and move
Date Tue, 04 Oct 2011 15:29:33 GMT
hi markus

regarding caches:

there are multiple caches involved but they should be cleared
or adjusted upon access control modifications i.e. adding,
removing or modification of an policy node.
one thing i can think of without taking a closer look at was
that the move operation of a parent node does not trigger an event
for those event-listeners that are interested in ac-modification
in order to keep the caches up to date...

to help us verify that a simple test case would be helpful.
you could e.g. add it to 
org.apache.jackrabbit.core.security.authorization.acl.WriteTest

regarding crx vs jackrabbit:

there is not difference in ac evaluation between crx and jackrabbit.

regarding alex' comment ("AFAIK if you change permissions, they will 
only apply to newly created sessions."):

that's not the case.

regards
angela


On 10/4/11 4:52 PM, Markus Joschko wrote:
> OK.  I now urgently need somebody to have a look at it. There must be
> something wrong with my test, as the results is otherwise quite
> discouraging.
> Even without a davex client in the mix.
>
> I uploaded a very simple Testservlet to
> https://gist.github.com/1261791 which can be installed in the
> jackrabbit-webapplication to make it easier to follow my experiments.
> The basic idea is to restrict read access to a subnode  and a property
> via rep:glob entries. The setup looks like that:
>
> /test1              ->  visible
> /test1/second  ->  visible
> /test1/sub       ->  hidden
> /test1/hidden   ->  hidden
>
> To get there, install the servlet and call setup on it (performed as
> admin): action=setup
>
> Next is to verify that the setup works as expected (performed as
> user1): action=dump
> That should show the following output (only visible nodes are listed):
>
> /test1 readable: OK
> /test1/second readable: OK
>
> Now do a move (admin): action=move&src=/test1&dest=/test2
>
> Verify that the moved nodes subnodes visibility is correct (user1
> session still open and used):
>
> /test2 readable: nt:unstructured: OK
> /test2/second readable: nt:unstructured: OK
>
> Fine until now. Next is to try a new session of user1. Logout user1:
> action=logout
>
> And login&dump again: action=dump
>
> /test2 readable: nt:unstructured: OK
> /test2/second readable: nt:unstructured: OK
> /test2/hidden readable: secret: ERROR!
> /test2/sub readable: nt:unstructured: ERROR!
>
> Why is that? And why is it only happen after relogin?
>
> Thanks,
>   Markus
>
>
>
>
>
>
>
> On Fri, Sep 30, 2011 at 6:00 PM, Alexander Klimetschek
> <aklimets@adobe.com>  wrote:
>> On 30.09.11 15:48, "Markus Joschko"<markus.joschko@gmail.com>  wrote:
>>> I am not completely sure on this. At the moment I am totally confused
>>> about the behavior.
>>> With a mix of davex client and serverside sessions I've seen the
>>> described leakage: Only for newly created sessions the acls applied.
>>>
>>> On the other hand I just have written a test that works solely with an
>>> embedded jackrabbit and two sessions (admin&  user) and here security
>>> seems to apply immediately on move, no leakage.
>>
>> If you use Workspace.move() that this is working outside of a session (no
>> session.save() needed), i.e. acts like a new session.
>>
>>> Should it really only work with newly created session then that is IMO
>>> a security risk.
>>
>> Hmm, yes, maybe I am wrong :-)
>>
>>> In a setup like /departmentA/topsecret where topsecret is denied in
>>> rep:glob, topsecret should certainly not be visible to anyone even
>>> when the department is moved to /departmentB.
>>
>> Yes.
>>
>> Alex
>>
>> --
>> Alexander Klimetschek
>> Developer // Adobe (Day) // Berlin - Basel
>>
>>
>>
>>
>>

Mime
View raw message