Subject: Re: ACL
To: Bill Studenmund <wrstuden@zembu.com>
From: Robert Watson <rwatson@FreeBSD.org>
List: tech-kern
Date: 04/11/2001 03:34:14
On Tue, 3 Apr 2001, Bill Studenmund wrote:

> I've not found many. I wanted to find ones for DCE, but didn't. The only
> ones I found were the Linux ACL folks and the TrustedBSD folks. One
> thing I'd point out about the Linux folks is that they are trying to
> impliment a POSIX (draft I think) standard. So it's not a Linux-invented
> thing. :-) 

For what it's worth, the TrustedBSD/FreeBSD ACL implementation is also
based on the (withdrawn) POSIX.1e spec, and applications seem to interop
quite well between the Linux and FreeBSD implementations.  While I dislike
the actual POSIX.1e ACL semantics (being a fan of AFS ACLs, which offer
simplicity and ease of management, but depend on file system properties
not available in UFS), I recognize both the portability and application
consistency benfits: POSIX.1e semantics are pretty close to those
implemented by most major UNIX operating systems, and the masking behavior
provides relatively safe mappings from application requests with
permissions into ACLs.  We're still committing some last pieces of library
infrastructure, but believe that applications such as Samba 2.2 should be
able to use our implementation without any substantial modification, which
we see as a big selling point.  FreeBSD 5.0-RELEASE will be the first
version of FreeBSD to ship with ACL support, although I expect it will be
considered experimental for some period of time as it receives broader
deployment, testing, and development.

The TrustedBSD implementation follows SGI's example by layering ACLs above
Extended Attributes for the purposes of storing ACLs in the file system
using a clean storage abstraction.  The Linux implementation later changed
to taking the same approach.  Right now, the FreeBSD ACL and EA
implementations are done at the UFS layer, mapping EAs into a backing file
in the style of the quota implementation.  The ACL implementation sits
cleanly above the EA interface, making the EA implementation an obvious
target for optimization.  It's easy to imagine an FFS implementation with
improved performance and consistency properties, and in fact we'll be
starting work on one shortly.  The benefits of starting with a UFS-based
implementation were that it provided for rapid development without on-disk
format changes, allowing forward progress on the ACL work, as well as
other projects such as POSIX.1e capabilities, MAC, etc. 

While the ACL interface is fairly stable, the EA interface is still the
subject of some amount of debate on {posix1e,linux-fsdevel,private}
mailing lists, and hopefully will firm up over the next few months through
continued cross-platform discussion.  We've seen substantial interest both
in the OpenBSD and Darwin communities in porting over the ACL and EA
implementations to their respective platforms (on Darwin, HFS+ features
can be taken advantage of to offer a cleaner EA implementation earlier --
funding will shortly be available for us to perform this work, in fact). 
If there is interest in the NetBSD community in porting these features
over, I would advise waiting until the interfaces and implementation on
FreeBSD get finished up and the EA interface is finalized (something that
may take a bit yet, due to disagreements about the acceptable level of
interface complexity, as well as application requirements). 

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