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 Thu, 06 Oct 2011 08:30:22 GMT
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,
>>>   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