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
<[email protected]> wrote:
On 30.09.11 15:48, "Markus Joschko"<[email protected]> 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
