Michael, this is EXCELLENT and a very good thing to go into the Wiki...please! I would but you should get the credit.
Michael Oliver CTO Alarius Systems LLC 3325 N. Nellis Blvd, #1 Las Vegas, NV 89115 Phone:(702)643-7425 Fax:(520)844-1036 *Note new email changed from [EMAIL PROTECTED] -----Original Message----- From: Michael Smith [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 12, 2005 3:20 PM To: Slide Users Mailing List Subject: Re: Question - is ACL negotiation unchangeable w/ competing rights ? 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]
