On Sat, 14 Apr 2001, John Hawkinson wrote:

> | I agree that AFS ACLs would be a good intermediate step. The one problem
> | with the code you mention is that it's encombered by the Transarc
> | restrictive license. :-( So while it could provide some info, it could
> | also taint the effort to add ACL support.
> 
> OpenAFS unencumbers this stuff.

Another potential source of code here is the pre-GPL Coda ACL
implementation, which is under a CMU license and derived from AFS2; I also
had a implementation of AFS-style ACLs on FreeBSD before we finalized on
POSIX.1e ACLs for the reasons I have described previously, but this code
might still be useful. 

While I'm a great fan of the AFS ACL model, it has a number of limitations
that make it hard to use in a normal UFS environment.  In particular:  AFS
asserts that hard links between files may only appear in the same
directory.  This means that they could place the ACLs only on directories
(a great simplification from the management perspective); however, this
has an important side effect: if a file appears in more than one
directory, then multiple ACLs apply to the file.  To have that work, the
access control decision is based on the path used to access the file,
which in turn means you need the ACL from the parent directory *and* the
file vnode when you want to make an access control decision.  In the *BSD
VFS stacks, you have access only to the file vnode (and therefore
meta-data associated with the file, not the directory).  There are a
number of ways you could work around this, but none are pretty, and many
do not preserve the elegant simplicity of the AFS model -- primarily that
files don't have protection properties themselves.  Another aspect of the
AFS protection scheme that made it so appealing was user-managed groups,
which allowed ACLs to often be short and to-the-point by avoiding
replicated user lists.

Robert N M Watson             FreeBSD Core Team, TrustedBSD Project
robert@fledge.watson.org      NAI Labs, Safeport Network Services