>But, in the design ofd 
>UNIX, a more general mechanism was instead thought up, which can be used
>for ACLs if one wishes: groups. 

I'm sorry, but I have to take issue with this statement.  Groups are
a compromise to space issues in relation to full ACLs.  You can do
ACL type stuff,  but ACLs are the more general mechanism.  Groups are
a very good compromise and have worked well in many applications.

Here are the problems I have with groups in general and on NetBSD
specifically.  

1) groups require system administration action to do ACL work.
If the administration doesn't want to help, you are out of luck.

2) Under the current implementation in NetBSD, a user may belong
to a maximum of 16 groups.  Let me quote <sys/syslimits.h>

#define NGROUPS_MAX                16   /* max supplemental group id's */

I discovered this because I recently wanted to have a class of
students create their own CVS repositories and do a long project
checking in and tagging each point where they were to turn in work.  I
wanted access to each CVS repository for grading and set up a
collection of groups with me and each individual student as the only
members of the group (the equivalent of the student giving me access
via an ACL to the directory).  This was to make sure students didn't
have access to each other's CVS repositories.

The result?  I couldn't login!  There were more than 16 students and
login wouldn't let me in since I had more than 16 supplementary
group Ids!  I not only had to recompile a kernel, CHANGING header
in sys/*, but I had to recompile all the user binaries that used
that constant!  And the supplementary groups are stored in a fixed
size array in the creds.  I can't easily adapt the kernel to
use a dynamic size supplementary group list even if I went back and
changed all the userland to deal with an arbitrary size supplementary
group list.  And, IIRC, the creds are used with NFS as well and that
is a box I don't want to even touch!

(Yes, I raised that constant to 64 on my system so I could do what
I wanted, but having a fixed limit like this AND allocating space
in user creds based on this fixed limit means groups in NetBSD can
not deal with large user bases and large combinations of ACL style
group manipulation.)


So, what would I do about this?  I have considered the idea of a
ACL fs ... basically a stackable file system that can be used with
any underlying FS and provides ACL for the underlying system.  Thus
it could be used over a MSDOS FS, or an ISO9660 system to provide
some form of protections.  I have not taken a lot of time in doing
a design, but this to me sounds like a resonable way to do ACLs.
No FS has to add ACL and one only pays the cost of ACLs on file
systems one wants ACLs on.  The two major issues (as I see it)
that would have to be resolved would be storage of the ACL-data
and methods to make sure the file system used and the ACL-data
match at mount time.  I'm sure other issues would arise, but this
sounds like a more general solution than adding ACLs to each and
every FS we support.

My $.02.
 
-- 
Phil Nelson
e-mail: philnelson@home.com  (Work: phil@cs.wwu.edu)
web: members.home.com/philnelson