jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Markus Joschko <markus.josc...@gmail.com>
Subject Re: ACLs, GlobPattern and move
Date Wed, 05 Oct 2011 10:41:41 GMT
Hi Angela,
I wrote two methods to demonstrate the behaviour:
https://gist.github.com/1261791#file_write_test.java
The two tests can simply be pasted into the WriteTest. They differ
from the other tests as they don't test for write but for read
privileges.

Both tests differ in just one line and both fail at the moment.
The first test fails at the privilege check after the move.
The second test fails already at the nodeExists check one line above.

assertFalse(testSession.nodeExists(movedchildchildPath));
assertFalse(testAcMgr.hasPrivileges(movedchildchildPath, read));

This is because in the second test the childchildPath is not tested
with nodeExists BEFOR the move.

So if nodeExists is checked on the node before the move, it succeeds
also after the move.
If it is not tested before the move, it fails after the move.

This is one of the oddities that drove me crazy.

Regards,
 Markus


On Tue, Oct 4, 2011 at 5:29 PM, Angela Schreiber <anchela@adobe.com> wrote:
> 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