Hi Ray, Thanks for testing and reporting this. You raise a good point. The ModifyAceServlet should handle updates involving aggregate privileges transparently. I'll re-open SLING-997 and work on an updated fix to address your scenario.
Regards, Eric On Tue, Feb 23, 2010 at 3:32 PM, Ray Davis <[email protected]> wrote: > While scoping this out I bumped into some behavior that surprised me. The > idea of SLING-997 is to merge newly specified privileges with any existing > ACEs for the principal. ModifyAceServlet does this by remembering any > existing ACE-included privileges which aren't mentioned *by name* in the > servlet input, merging them with the servlet-specified privilege lists, and > then adding the merged lists as two ACEs, first the grants and then the > denies. Jackrabbit's handling of aggregate privileges can put an interesting > twist on this, though: > > === > > curl -u admin:admin http://localhost:8080/content/anode.acl.json > {"inst":{"granted":["jcr:read"],"denied":["jcr:write"]}} > > # The next request will have no effect because denied "write" will be > applied after granted "modifyProperties": > > curl -u admin:admin -FprincipalId=inst > -fprivil...@jcr:modifyProperties=granted > http://localhost:8080/content/anode.modifyAce.html > > curl -u admin:admin http://localhost:8080/content/anode.acl.json > {"inst":{"granted":["jcr:read"],"denied":["jcr:write"]}} > > # This will have no effect because "all" is not stored in an ACE: > > curl -u admin:admin -FprincipalId=inst > -fprivil...@jcr:modifyProperties=granted > -fprivil...@jcr:all=none > http://localhost:8080/content/anode.modifyAce.html > > curl -u admin:admin http://localhost:8080/content/anode.acl.json > {"inst":{"granted":["jcr:read"],"denied":["jcr:write"]}} > > # This is the only way to handle it: > > curl -u admin:admin -FprincipalId=inst > -fprivil...@jcr:modifyProperties=granted > -fprivil...@jcr:write=none > http://localhost:8080/content/anode.modifyAce.html > > curl -u admin:admin http://localhost:8080/content/anode.acl.json > {"inst":{"granted":["jcr:modifyProperties","jcr:read"]}} > > == > > Does this seem OK, so long as the ModifyAceServlet JavaDoc and > http://sling.apache.org/site/managing-permissions-jackrabbitaccessmanager.htmlget > updated to explain the behavior? Or should Sling try to disaggregate > privileges when checking for changes? > > Thanks, > Ray > > > On 2/22/10 9:53 AM, Ray Davis wrote: > >> I happened to be looking at the ModifyAceServlet issue described at >> SLING-997 late last week and noticed almost exactly the same logic >> (except without the bug) in >> jcr/contentloader/internal/DefaultContentCreator. In the Sakai 3 >> project, Ian added a utility method to consolidate the same rather >> complex logic of replacing access controls for a specific Principal on a >> specific path, and it's proven very popular among service developers. >> >> I'd like to try submitting a similar utility method to Sling, but wanted >> to check with the development team first in case there's a conflict with >> other near-term authz tasks. >> >> Thanks, >> Ray >> >
