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 Thu, 06 Oct 2011 08:16:46 GMT
hi markus

it's actually as i suspected. in fact this is not an issue with
restrictions but a general problem. anyway: i created JCR-3095
to follow up on this.

regards
angela

[1] https://issues.apache.org/jira/browse/JCR-3095

On 10/5/11 1:39 PM, Angela Schreiber wrote:
> 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