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 <[email protected]> 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<[email protected]> >>> 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 >>>>> <[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 >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>> >
