Subject: Re: ACL stuff
To: Darren Reed <darrenr@vitruvius.arbld.unimelb.edu.au>
From: John F. Woods <jfw@jfwhome.funhouse.com>
List: current-users
Date: 04/20/1995 13:05:54
> > How is this ACL stuff going to affect all the user-land code that
> > calculates access permissions by calling stat(), getuid(), getgroups()
> > because of the generations of programmers that have been told the evils
> > of calling access().

Generally programmers have been told that access() is evil when called by
non setuid programs to determine if an operation might fail; the correct
approach is to simply *do* the operation and let it fail, not to go to bizarre
lengths to re-implement what access() might have done.  Setuid programs have
always been supposed to call access() (or better yet, attempt to arrange for
the operations to be performed as the original user ID).  What this does to
programmers who have needlessly reimplemented access() is to offer an
opportunity to be told "I TOLD YOU SO!"

> What needs to be considered carefully is in which order and with what
> hierarchy does the ACL have wrt owner/group/other permissions ?

I think what makes the most sense is for the ACL to be inspected only if the
traditional mode word is 0 (modulo setXid bits).  The ACL system then has to
be flexible enough to easily implement "rwxrwxrwx except for barney, who gets
nothing", which would be the kind of thing you'd like to have ACLs interact
with the traditional mechanism for.

A slightly less extreme view might be to check the ACL system if the 3 bits
corresponding to your access to a file are zero, so that "rwxrwx--- + ACL"
could efficiently give permission to owner, group, and a handful of others.