>I've tried setting foo, foo2 and foo3 this way:
><permission action="/actions/read" subject="user" inheritable="false"
>negative="true" />
>This will hide foo1-3 but when I add an ACL for user1 to enable read for
foo2:
><permission action="/actions/read" subject="/users/user1"
inheritable="false" >negative="false" />
>user1 cannot access foo2 because he is a member of the "user" role which
was set to
>read = false. Is this a bug? I would think that user1 should be able to
access the
>collection since his read rights are explicitly stated.
It's not a bug depending on the policy. Right now, the policy if :
- If not explicitely granted, then deny
- If denied and granted on the same node, then deny (always)
I was considering about adding some specificity rules in the second case,
like the one you mention above (the principal is more specific tham its
role), but then the ACL checking algorithm would get more complex.
I plan to do a limited rewrite of the ACL check algorith soon (to support
groups more cleanly), so I'll add it on the feature list.
>Can someone please tell me how to accomplish this?
If you don't grant something, then it will be denied. If you don't say user
can read foo1-2-3, then you're safe (unless, of course, some permission is
inherited from above).
Remy
