>From a security standpoint the concept of an all-powerful admin is a bad thing. The new ACL-type implementations I've seen seem to moving to a more localized security policy where it's easier to control who has access to a resource and it's easier to contain a security breach (since no one account has access to the whole system). That being said, we've found it very useful to have an admin account that can un-stick bad ACLs.
That's one thing I don't like about Slide's ACL implementation. It's possible for anyone with the write-acl permission on an object to completely fubar it (deny all to all) in such a way that can only be fixed by stopping Slide and mucking with the store directly. I should check the ACL spec again, but I think it allows for an implicit "grant all to owner" implementation. As it is now my security front end always sets "grant all to owner" and "grant all to admin" as the top two permissions in an ACL, but if we ever move to smarter WebDAV fat-clients I'm going to be in trouble :). -James On Thu, 2005-01-13 at 12:01 +0900, Carlos Villegas wrote: > This is ok, but the issue is that when checking the ACL for a user > belonging to several groups, the first one that explicitly grants/denies > access is the one that takes effect. This sounds right but sometimes is > not what you expect. For example, you have an admin group that you've > given full access to a top directory, then in some subdirectory you > denied access to another group. If you have a user that belongs to both > groups it will be denied access to the given subdirectory even if he > belongs to the admin group because the inherited ACEs come last in the > ACL. Of course, you can explicity grant access to the admin group in the > subdirectory's ACL, but it kind of defeats the purpose of inherited > ACLs. Reading the spec it looks like this is the way that it has to be, > but it doesn't sound logical in situations like the above. > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
