Ray, I applied a new patch in r915670.
Can you please verify that this addresses your concerns? Thanks! Eric On Tue, Feb 23, 2010 at 7:42 PM, Eric Norman <[email protected]>wrote: > 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 >>> >> >
