On Sat, 25 Aug 2001, Ken Cross wrote:

> > And (imho) it belongs at the UFS layer anyway, so that we get it
> > in other file systems. (Yes, I have a specific LFS disk in mind
> > where I want ACLs, thanks for not asking.)
> 
> In the current FreeBSD implementation, the ACL's are stored in a
> separate file, one per filesystem.  I think the inode number is an index
> into the file for where the ACL is stored (it's a fixed size and you
> certainly don't want a sequential search).  The inode and the on-disk
> structure for the files themselves are not changed.  This has pros and
> cons, but it's straightforward and reasonably portable. 
> 
> If Robert Watson and friends are lurking on the list, they can give a
> much better overview than I.  http://www.trustedbsd.org/ has some info,
> but most details are buried in the source code and mailing lists. 

I'd be happy to talk about what we've done on FreeBSD (and are now doing
on Darwin and are looking at doing on OpenBSD).  For reference purposes,
I'd also refer you to the BSDCon paper on TrustedBSD work last year, and
the USENIX paper this year.

FreeBSD implements ACLs in UFS/FFS by layering them above a generic
meta-data service named "Extended Attributes".  Both EAs and ACLs are
exposed at the VFS layer, and the mapping of ACLs into EAs is performed
inside UFS (so ACLs can be stored other places easily).  EAs provide the
ability to bind sets of (name,value) pairs with files.  Right now extended
attributes are stored in backing files, but we have DARPA funding to
re-implent EAs as part of FFS at the file system level.  There are many
benefits to taking the EA approach, including hiding the storage of ACLs
from the ACL implementation allowing it to be easily changed.  Also, it
gives us the ability to store labeling information for other security
work, such as MAC, Capabilities, et al.  A number of other platforms have
elected to follow this approach also, including XFS on IRIX.  This differs
from the approach taken with Solaris, where ACL storage isn't abstracted
(the twin inode technique).  The performance of the current EA technique
isn't incredible, but it's also acceptable for many uses--since the EA
implementation is entirely pluggable, it's easy to change this, and we
will be over time.

We use POSIX.1e semantics and syntax (with some BSD tweaks for things like
fd's on directories), which are similarly uninspiring, but pretty
functional, as well as portable.

All of this work should be easily portable to NetBSD, as we've already to
some extent demonstrated on Darwin, and now OpenBSD.  I'd be happy to
field any questions people might have about the design, implementation,
performance, compatibility, etc.  I can also point at various documents,
including POSIX1e, our papers on implementation, etc.

To understand the 5.0 implementation, take a look at vnode_if.src,
ufs_extattr.c, ufs_acl.c, kern_acl.c, and src/lib/libc/posix1e/acl*, as
well as src/bin/{getfacl,setfacl}.

> > So, then, what can we do to allow an ACL-aware kernel to still
> > behave correctly with an old-style {F,U}FS partition (that's the
> > easy part), and what can we do to make a non-ACL-aware kernel able
> > to read a file system with ACLs (that's the hard part).
> 
> Keep in mind that ACL's are in addition to standard mode bits, so
> non-ACL-aware kernels can be in blissful ignorance without
> modifications. 
> 
> Similarly, ACL-aware kernels easily handle non-ACL files.  The library
> routines specified in 1003.1e are used to get/set/evaluate the ACL's. 
> These routines are supplied by the filesystem.  The kernel doesn't need
> to know anything about the internal structure of the ACL itself. 

This stuff is scary, but works :-).



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