Mailing-List: contact users-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@jackrabbit.apache.org
Received-SPF: pass (athena.apache.org: domain of markus.joschko@gmail.com
 designates 209.85.213.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <4E8D63EE.6050104@adobe.com>
References: 
 <CAKhi2WN1yMwxUB9RCOgpMvV5-vEaGyvLgMFfSi3YxsU6Vn0F=Q@mail.gmail.com>
	<CAABB28E.8C17D%aklimets@adobe.com>
	<CAKhi2WMzdU-CX7SPPxPAu5_i7-9gfJvxmn=+SRX3Pe05b9-KSw@mail.gmail.com>
	<4E8B265D.1010707@adobe.com>
	<CAKhi2WPfudMCK4U4s3zONqveutR_9vbWAH-51usnAMqibs-=GQ@mail.gmail.com>
	<4E8C4200.7080609@adobe.com>
	<4E8D63EE.6050104@adobe.com>
Date: Thu, 6 Oct 2011 10:30:22 +0200
Message-ID: 
 <CAKhi2WMyxyu=iE0yR8vT7MQHuC56JQU7J2eg74qdJhutwKjd5A@mail.gmail.com>
Subject: Re: ACLs, GlobPattern and move
From: Markus Joschko <markus.joschko@gmail.com>
To: users@jackrabbit.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi Angela,
I already voted for it.
As we need to protect properties on nodes that are frequently moved
that is a real blocker.

Regards,
 Markus

On Thu, Oct 6, 2011 at 10:16 AM, Angela Schreiber <anchela@adobe.com> wrote=
:
> 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,
>>> =A0 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. =A0I 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 =A0and a prope=
rty
>>>>> via rep:glob entries. The setup looks like that:
>>>>>
>>>>> /test1 =A0 =A0 =A0 =A0 =A0 =A0 =A0-> =A0 =A0 visible
>>>>> /test1/second =A0-> =A0 =A0 visible
>>>>> /test1/sub =A0 =A0 =A0 -> =A0 =A0 hidden
>>>>> /test1/hidden =A0 -> =A0 =A0 hidden
>>>>>
>>>>> To get there, install the servlet and call setup on it (performed as
>>>>> admin): action=3Dsetup
>>>>>
>>>>> Next is to verify that the setup works as expected (performed as
>>>>> user1): action=3Ddump
>>>>> That should show the following output (only visible nodes are listed)=
:
>>>>>
>>>>> /test1 readable: OK
>>>>> /test1/second readable: OK
>>>>>
>>>>> Now do a move (admin): action=3Dmove&src=3D/test1&dest=3D/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=3Dlogout
>>>>>
>>>>> And login&dump again: action=3Ddump
>>>>>
>>>>> /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,
>>>>> =A0 Markus
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Fri, Sep 30, 2011 at 6:00 PM, Alexander Klimetschek
>>>>> <aklimets@adobe.com> =A0 =A0 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 confus=
ed
>>>>>>> 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& =A0 =A0 user) and here
>>>>>>> security
>>>>>>> seems to apply immediately on move, no leakage.
>>>>>>
>>>>>> If you use Workspace.move() that this is working outside of a sessio=
n
>>>>>> (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
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>
>