A way to implement this other behaviour, is to evaluate the whole ACL for each group a user belongs to separately and then choose the one that gives higher access. Resolving group strength at the time each ACE is evaluated will not work because, as Nick explains, an ACE may say nothing about a particular group but that doesn't mean that for that group at this point, access has been granted or denied.
Carlos
Michael Smith wrote:
Nick Longinow wrote:
Hi
If a resource (document) in Slide has an ACL with multiple entries for the
same principal, the spec (as I recall it) says that the lesser permission is
applied to requests. ie, if user has read-only access as a member of one
group, and read-write as a member of another group, both of which are named
in the resource's ACL, then the user is given only the lesser (read-only).
Is there a way to modify this behaviour, ie, such that either the first or
last permission is applied ? Ideas ?
Nick
Nick,
Your understanding of how this works isn't quite right. The ACL spec doesn't say anything about the relative 'strengths' of rights, the only thing that matters is the order within the ACL.
The way it works is this:
1) you want to figure out if a user can perform some action (for example: writing to resource X)
2) You look at each ACE on resource X _in order_. The order of evaluation is: direct permissions on the resource (in their explicit ordering within the ACL), then inherited permissions from the parent, then inherited permissions from the grandparent, etc.
3) If this permission allows you to perform the appropriate action, then the access control checks pass. Don't look at the rest of the ACEs
4) If this permission _denies_ the appropriate permission, the access control check fails. Don't look at the rest of the ACEs.
5) If this permission does neither, continue to the next ACE. This is common - a 'read' permission, for example, doesn't allow writes, but doesn't deny them either.
So the default behaviour (I think you can plug in alternative implementations, by the way, to answer your original question - but that would likely make it incompatible with the ACL spec) will be that, in your example, things 'just work'. However, this depends on exactly how you've set up your permissions.
Specifically, you said "user has read-only access as a member of one group". There are two ways you could set that up. One would be to say "this group has read access" (and say nothing at all about write access!), the other would be to say "this group has read access AND this group explicitly does not have write access", using two ACEs (a grant and a deny). This latter form would not do what you want, so you should avoid it.
Mike
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
