ACL implementation on FreeSBD: semantics/standards/etc

[Robert Watson]

On Mon, 17 Jan 2000, Andreas Gruenbacher wrote:

> I have a (hopefully) compliant implementation of Draft 17. Various
> backends can be implemented, such as Linux, Solaris, FreeBSD, etc.
> 
> The ACL library was pretty awful to implement, and the whole thing isn't
> extremely efficient. Given that Draft 17 is the only specification we
> have at all, I decided to implement that rather than anything new. The
> library includes a few extensions, however. See
> <http://acl.bestbits.at/pre/acl-0.5.6-pre20.tar.gz> (the current
> prerelease version).
> 
> I'd guess it's better to use that code rather than re-implement it for
> FreeBSD.  The getfacl / setfacl utilities are based on that library, so
> they come for free once another backend is written. 

I will take a look at that, thanks!

> I see you have used the Posix names for your functions that have a
> different signature. This will probably cause name clashes. 

I was under the impression (possibly false) that I had followed POSIX.1e
pretty closely for the interface routines (D17).  Could you point me at
which I got wrong?  I don't have a copy of the spec easily at hand right
now.

> > I introduced the following non-POSIX.1e interfaces:
> > int     acl_delete_def_fd(int filedes);
> 
> This is not possible on Linux. It makes sense to include such a function
> for OSes that support it, however, and would be a trivial extension to
> the library. 

Yes.

> > int     acl_valid_file(const char *pathp, acl_type_t type, acl_t acl);
> > int     acl_valid_fd(int fd, acl_type_t type, acl_t acl);
> 
> Probably a good idea. We have limited our efforts to Posix ACLs at the
> moment.  The system calls support additional semantics, but that's it. 

We've found it particularly helpful for Arla/Coda although we don't have
implementations using it yet.  Assar from the Arla project was especially
interested (he actually ported my code forwards to -current of FreeBSD
before I did :-)  The one thing this complicates is that originally, in my
first pass, I required userland processes to sort ACLs before submitting
them to the kernel, meaning that the in-kernel verification of the ACL
happened in O(n) rather than O(n log n) including a sort.  The question
arrises, with differing semantics, when you should and shouldn't sort, so
I added a hackish acl_posix1e() call that looks for ACLs that loko a bit
like POSIX.1e ACLs (i.e., the right tags, etc) and sorts only those ACLs.

  Robert N M Watson 

robert at fledge.watson.org              http://www.watson.org/~robert/
PGP key fingerprint: AF B5 5F FF A6 4A 79 37  ED 5F 55 E9 58 04 6A B1
TIS Labs at Network Associates, Safeport Network Services

To Unsubscribe: send mail to majordomo at cyrus.watson.org
with "unsubscribe posix1e" in the body of the message