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.html
get 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
