Permission systems with ACLs (was RE: About the login shell)
Lionel Elie Mamane wrote:
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:
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).
I'm thinking a Deny ACE automatically overrides any Allow ACE, but with
no inheritance.
For example, say there's an "allow write to Lionel" ACE on
/home/tom/public/, but a "deny write to Lionel" ACE on /home/tom/. Since
the Deny ACE isn't inherited, there is no need for order dependency.
If there were a "Deny Read" and "Deny Execute" ACE's on /home/tom/, then
it would be as if, when you try to access /home/tom/, the "other" bits
were turned off. But this would only affect the user to which the ACE
applies.
Am I missing something here?
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?
Yup.
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.
Ok, continuing with your example: I'm a plotter. The sysadmin gives all
employees and board members access to set permissions on their own
files, but not to create new groups. Furthermore, the sysadmin has more
important things to do than make a group for people I trust.
Hence the only way I can block the chairman is with a Deny ACE, or by
removing the "Allow access to group board" ACE, and explicitly adding
ACEs for all the plotters.
True, this leaves me open to my adversary employing an agent. But
creating a new group may not always be possible.
Also, Deny ACEs become more interesting in the context of groups, I
think, since they correspond to the set difference operation. For
example, take the groups "Students" and "Untrusted Students". Using an
Allow ACE for Students and a Deny ACE for Untrusted Students amounts to
having an Allow ACE for the group "Trusted Students" (without explicitly
creating this group).
Perhaps the system could keep track of "Virtual Groups" somehow; that
is, specify in some system file that "Trusted Students = Students -
Untrusted Students". Then the group Trusted Students could be referred
to, and would change automatically when Untrusted Students was changed.
This would renden Deny ACEs unneccessary in the Group A - Group B case.
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...
Yes, that does sound like a cool project.
-- Tom Hart
hartte13@brandonu.ca
Reply to: