This should be discussed at the webdav mailinglist directly as it is of interest for all other WebDAV-server vendors. I'd encourage everyone to join the w3c-dist-auth at w3.org mailing list. Cheers, Daniel
"Slide Users Mailing List" <[email protected]> schrieb am 13.01.05 04:02:17: > > 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] > __________________________________________________________ Mit WEB.DE FreePhone mit hoechster Qualitaet ab 0 Ct./Min. weltweit telefonieren! http://freephone.web.de/?mc=021201 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
