On Wed, Aug 21, 2002 at 11:29:04AM -0500, Tom Hart wrote: > Lionel Elie Mamane wrote: >>On Tue, Aug 20, 2002 at 11:28:07AM -0500, Tom Hart wrote: >> Maybe I should describe what I know of the ACL's implemented on top >> of Unix then: I had some experience with a Solaris system, and I >> heard that the (since withdrawn) POSIX ACL draft was very close to >> this. >> Does this "version" of ACL's calm your fears of ACL's being >> "unintuitive"? > Ah, yes, this seems more intuitive, and more Unixy. That would be a Good > Thing. > I think the non-intuitiveness of NT ACLs comes mainly from their > order-dependent nature, coupled with ACE inheritance. > The one thing about NT's approach that I think is good is the > presence of Deny ACEs. I feel like one can't have Deny ACEs without order dependency. And that is a bad thing, except maybe with explicit priority (each AC entry has an explicit priority number and they are applied in that order). While ACE is an additional feature, I think trying to avoid creeping featurism is a good thing, too. And I can't come up with a sensible scenario where Deny ACEs make sense, where they really make things better for the user, or the administrator or ... You think you can: > And I suspect that there are many situations in which it would be > more convenient to add a Deny ACE to a file than to have to make a > new group that excludes the person to whom you'd like to deny > access. I'm curious to hear about such a scenario. With all examples that pop-up in my head, using Deny ACEs actually would be an example of bad administration, or rules that won't hold the passage of time. It all revolves around "why do you want to exclude this one person"? I don't see any reason that would apply to one person and NEVER to a new member of the group. If you give access to group G, and user U is in G, but you don't want to give access to group G, then either: - G is not the right group you want to give access to. E.g. you confuse staff members (administrators) and staff members being formed (learning the system) (so you don't want to give them the power to wreak havoc in the system, but the power to do small administrations tasks). Maybe in *your* organisation, those two groups differ by only one person, but conceptually, they are *not* the same. - U does not belong in G. Fix _that_. You understand what I mean? E.g., if you are member of the board of the Big A Corp., and you are plotting to throw the chairman out. You don't want the chairman to be able to read your plans, OK. But then giving access to board member, and a Deny ACE for the chairman is not the right answer: You want that only plotters access the plans. If a new board members is accepted, you don't want him to automatically have access to the plans: he might be the chairman's pawn. In school, student Q already has stolen your work before, so you want to deny him access to your working drafts. Again, this new kid in school can become a friend of Q, so you won't want him to have automatic access either. So 'all students access, except Q' isn't quite right either. In a different direction, it has just struck me that on a GNU/Hurd system, I don't need to whole filesystem to support ACL's to have fine-grained control over who access my files: Just write my own translator :) Hmm... This would be a nice toy project to get some experience with the system... -- Lionel
Attachment:
pgpTge1HMHfhY.pgp
Description: PGP signature