Oh... I get it. There's no ACL on the user and group nodes in the security workspace.
But trying to apply an ACL to / or /rep:security returns an exception $ curl-FprincipalId=anonymous -fprivil...@jcr:all=denied http://admin:ad...@localhost:8888/rep:security.modifyAce.html?sling.workspace=security <html> <head> <title>Error while processing security:/rep:security</title> </head> <body> <h1>Error while processing security:/rep:security</h1> <table> <tbody> <tr> <td>Status</td> <td><div id="Status">500</div></td> </tr> <tr> <td>Message</td> <td><div id="Message">javax.jcr.RepositoryException: Failed to create ace.</div></td> </tr> <tr> <td>Location</td> <td><a href="/_rep_security" id="Location">/_rep_security</a></td> </tr> <tr> <td>Parent Location</td> <td><a href="/" id="ParentLocation">/</a></td> </tr> <tr> <td>Path</td> <td><div id="Path">security:/rep:security</div></td> </tr> <tr> <td>Referer</td> <td><a href="" id="Referer"></a></td> </tr> <tr> <td>ChangeLog</td> <td><div id="ChangeLog"><pre></pre></div></td> </tr> </tbody> </table> <p><a href="">Go Back</a></p> <p><a href="/_rep_security">Modified Resource</a></p> <p><a href="/">Parent of Modified Resource</a></p> </body> </html> On 9/11/10 10:25 AM, Felix Meschberger wrote: > Hi, > > Unless I am completely mistaken, the usermanager uses the request's > session to get at the Jackrabbit UserManager to do any tasks, which is > the absolutely correct thing IMHO. > > We should definitely leave this kind of access control to Jackrabbit > (resp. the configured functionality of Jackrabbit) and not impose our > own idea ontop of it. > > There is one situation where an admin session is always retrieved: The > CreeateUser servlet. This is probably a bug and should only use an admin > session for self-registration. > > Regards > Felix > > Am 10.09.2010 00:47, schrieb Mike Moulton: >> I recently had the need to get a list of users from an AJAX style client and >> found the jackrabbit usermanager exposes this functionality at >> system/userManager/user. As a part of this discovery, I noticed the listing >> of JCR users is not restricted in any way. If the usermanager bundle is >> installed, the following endpoint is open to the public: >> http://localhost:8080/system/userManager/user.tidy.1.json, providing a >> complete user list to anyone digging around. Any usermanager command that >> allows modifications to the JCR first checks if the user is an admin, but it >> seems all the read-only commands skip this check. >> >> Is this by intention, or was this simply missed? >> >> In addition, what are the thoughts on adding some sort of authorization >> component beyond just the isAdmin check? Maybe inspecting the >> jcr:readAccessControl / jcr:modifyAccessControl for the root node? >> >> -- Mike
