[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: About the login shell

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

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...


Attachment: pgpPOXHi6z9Xh.pgp
Description: PGP signature

Reply to: