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

No, no, and no again.

First you check if the current UID is in the ACL.  If so, you use the
permissions from this ACL entry to validate.  Then you check if any of
the groups are in the ACL.  If so, you use the permissions from these
ACL entries to validate.  With the groups, you will have to either define
an open system, or a closed one.  (Examples below)

Then you do the normal check, if you do not have an OK or DENIED yet, done
in the ufs_access() function in the kernel.  After this check, you have
either an OK, or DENIED.

Example:
--------
+rwxr-xr--   foo   bar   ./testfile
	wendy.*      r-x
	*.sys        r-x
	*.noaccess   ---

Here, ./testfile is owned by 'foo', and group 'bar'.

Any user with the UID of 'wendy' will have read, write, and execute
access to this file.

Any user with the GID of 'sys' and not GID 'noaccess' will also have
read, write, and execute access to this file.

Any user with the GID of 'noaccess' and not GID 'sys' will have no
access to this file whatsoever.

Any user with UID != foo && UID != wendy && GID != sys && GID != noaccess
and GID == bar would have r-x.

Any user with UID != foo && UID != wendy && GID != sys && GID != noaccess
and GID != bar would have r--.


There are at least 2 problems here:

What if UID == 'wendy' && GID == 'noaccess'?  In my opinion, the more
specific one, UID == 'wendy' should apply.

What if GID == 'sys' && GID == 'noaccess'?  In my opinion, the more
restrictive (maybe compile time option?) should apply.


Another nice thing to have, would be the ability to have 'extra' bits
in the ACL entries, a bit to allow protection changes 'p' could be very
usefull.  Also, a bit 'd', to allow deletions could allso be usefull, etc...



Also, to make the lookup faster (for the case where a file does not have
an ACL), the same place where the imutable flag is set in the inode, we
could have an ACL present flag.  Only if this bit is set on an inode, do 
we have to check the ACL lists...

--Toby.
*----------------------------------------------------------------------------*
| Tobias Weingartner | Email: weingart@BrandonU.Ca | Need a Unix sys-admin?  |
| Box 27, Beulah, MB |-----------------------------| Send E-Mail for resume, |
| R0M 0B0, Canada    | Unix Guru, Admin, Sys-Prgmr | and other details...    |
|----------------------------------------------------------------------------|
|      %SYSTEM-F-ANARCHISM, The operating system has been overthrown         |
*----------------------------------------------------------------------------*