> >> Try to learn from VMS (DEC). There you can see how to implement ACLs!
> 
> >i've not used VMS acls, but...  (somebody's going to shoot me for this 8-)
> >i'm _really_ starting to like AFS ACLs...  8-)
> 
> Actually, somebody is going to shoot me with high-powered artillery
> for this, but Windows NT does a great job with ACLs also.
> 

Well, I just took a look at the linux ext2fs system, and got fairly simple
way to change ufs_access() to support ACLs for some filesystems.  By using
2 reserved inodes, you could implement the following:

Inode #1: Bad block list  (Traditional, still true?)
Inode #2: Root directory  (Still true?)
Inode #3: ACL.dir file    (Proposed)
Inode #4: ACL.dat file    (Proposed)

Format of /ACL.dir file:      Format of /ACL.dat file:
|--------------------------|  |--------------------------|
| Various Header info...   |  | Various Header info...   |
| Magic numbers, versions, |  | Magic numbers, versions, |  
| etc...                   |  | etc...                   |  
|--------------------------|  |--------------------------|  
| Pointer to data for      |  | UID 1, Access Mode       |
| Inode #1  (fixed length) |  |  :      :      :         |
|--------------------------|  | UID n, Access Mode       |
| Pointer to data for      |  | GID 1, Access Mode       |
| Inode #2  (fixed length) |  |  :      :      :         |
|--------------------------|  | GID n, Access Mode       |
:            :             :  |   ACL for inode #?       |
|--------------------------|  |--------------------------|
| Pointer to data for      |  :            :             :
| Inode #3  (fixed length) |  |--------------------------|
|--------------------------|


This would give a simple, and fairly quick way to get at the ACLs
from within one piece of code.  Basically, after checking the UID
and GIDs for access, the OS would check the ACLs if any existed.
To read in an ACL, ufs_access() would need to do (if not cached)
at most 2 reads, one to get the pointer from the directory file,
and usually one to read in the ACLs from the data file.

The "neat" thing here is the possibility of sharing ACL entries,
between files.  Given the header information, default ACL entries
could also be implemented.  Another nice thing, is the fact that
inodes would not have to change in order to implement this.  Also,
the implementation of lsacl, rmacl, chacl, edacl, and libacl.a
should be pretty trivial.  Also, note that ACL.dir and ACL.dat
are arbitrary filenames, only needed for user land utilities.
The kernel can go right after the inodes themselves.

On the down side of things, this will slow things down.  We could
cache things (besides the buffer cache) in the kernel, but that
means that to change ACLs and get them updated in the kernel would
mean at the very least some flushing code being added to various
modules.  I don't think adding another system call to handle this
(a la quotactl, etc) is necessary.  Another thing which I can't
seem to get my mind around is a slight chicken and egg problem.
How do I read the ACL.dir and ACL.dat files from within ufs_access()?
If I do an 'open' on the file, ufs_access() will get called recursively.
One way would be to disallow ACLs on the ACL.* files, which would
effectively elliminate the recursion.  However, I think ACLs on the
ACL.* files could be *very* usefull, as it could give someone a type
of BYPASS (VMS parlance) privilidge, in the sense that this person
could add, del, and edit ACLs on files without root privlidge. (sp?)

Also, fsck would have to be modified slightly (again).  To prevent this
sort of thing in the future, why not provide a field in the superblock
which specifies the number of inodes that are reserved for system
purposes.  (That way we don't have to re-write fsck to move files
from a now reserved inode to a ok one, and changing all the hard
links to the file as well...)

Another down side is the fact that you can not have directory default
ACLs, without a little more structure in the ACL.dat file.  Personally,
I think directory default ACLs are nice, but not a necessity right from
the start.  I figure if we make the files and libraries to access this
information extensible, this sort of things could be added sometime in
the future.


Yikes, I am rambling again.  Please, I would like people to really
disect this, and send me responses.  If I get a favourable response,
and some way to read the ACL.* files from within ufs_access(), I
think I will try my hand at some kernel hacking... ;-)


PS:
Can someone who knows the kernel stuff slightly better than I either
confirm, or refute the following slight patch:

vfs_lockf.c: line 218
-                     free(lock, M_LOCKF);
+                     FREE(lock, M_LOCKF);

I don't think it will make any difference.  But the rest of the file
seems to use FREE(), so I thought the sole free() might want to be
changed...



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