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 Wed, 05 Oct 2011 11:39:44 GMT
hi markus

thanks for the tests. i will take a closer look and provide feedback as 
soon as possible.
regards
angela

On 10/5/11 12:41 PM, Markus Joschko wrote:
> 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