You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@jackrabbit.apache.org by Markus Joschko <ma...@gmail.com> on 2011/10/04 16:52:31 UTC
Re: ACLs, GlobPattern and move
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
<ak...@adobe.com> wrote:
> On 30.09.11 15:48, "Markus Joschko" <ma...@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
>
>
>
>
>
Re: ACLs, GlobPattern and move
Posted by Markus Joschko <ma...@gmail.com>.
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 <an...@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<an...@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
>>>>> <ak...@adobe.com> wrote:
>>>>>>
>>>>>> On 30.09.11 15:48, "Markus Joschko"<ma...@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
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>
>
Re: ACLs, GlobPattern and move
Posted by Angela Schreiber <an...@adobe.com>.
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<an...@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
>>>> <ak...@adobe.com> wrote:
>>>>>
>>>>> On 30.09.11 15:48, "Markus Joschko"<ma...@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
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>
Re: ACLs, GlobPattern and move
Posted by Angela Schreiber <an...@adobe.com>.
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<an...@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
>>> <ak...@adobe.com> wrote:
>>>>
>>>> On 30.09.11 15:48, "Markus Joschko"<ma...@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
>>>>
>>>>
>>>>
>>>>
>>>>
>>
Re: ACLs, GlobPattern and move
Posted by Markus Joschko <ma...@gmail.com>.
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 <an...@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
>> <ak...@adobe.com> wrote:
>>>
>>> On 30.09.11 15:48, "Markus Joschko"<ma...@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
>>>
>>>
>>>
>>>
>>>
>
Re: ACLs, GlobPattern and move
Posted by Angela Schreiber <an...@adobe.com>.
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
> <ak...@adobe.com> wrote:
>> On 30.09.11 15:48, "Markus Joschko"<ma...@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
>>
>>
>>
>>
>>