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 > > > > >
