ACL implementation on FreeSBD: semantics/standards/etc

[Andreas Gruenbacher]

Robert Watson wrote:
> 
> So I have pretty much finished implementing ACLs in FreeBSD--in 4.0, we'll be
> shipping with the ACL interface in there, although not support in UFS/FFS for
> the time being.  To make the POSIX.1e ACL spec fit our needs, I made a number
> of design choices that either resolve ambiguities in the spec, or diverge from
> the spec :-).  I thought I'd post a description of some of the things I did to
> see if there was any other past experience in these areas, or concensus on the
> approach, as well as to see if anyone had objections to the approaches :-).
> 
> 1) Scrap the POSIX.1e ACL editing library, limiting interfaces to
> allocating, freeing, validating, converting, getting, and setting of ACLs.
> I found the editing library counter-intuitive and problematic to implement
> given the ACL storage format I chose.

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 see you have used the Posix names for your functions that have a different
signature. This will probably cause name clashes.

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

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

> 2) Userland interface
> 
> Getfacl was easy to implement given these calls.  However, setfacl makes
> reference to short ACLs being combined with relative permissions.  This
> behavior wasn't well-defined, in my view, and I'm interested to see how others
> interpretted and implemented this behavior.  Relative ACLs seem useful,
> although they do introduce a race condition given the POSIX.1e get/set
> interface, as there is no atomic get/modify/set behavior.  Locking could
> be used to implement this, however.  For the time being, we have no plans to
> ship a getfacl/setfacl with FreeBSD 4.0, but if I can resolve this then we
> would go ahead and ship with it.

I implemented getfacl/setfacl using my library. It can be brought in Posix
compatibility mode (which makes the utilities quite hard to use) with the
POSIXLY_CORRECT environment variable. In their native mode, they behave more
like the Solaris tools. These are the manual pages:

<http://acl.bestbits.at/man/getfacl.html>
<http://acl.bestbits.at/man/setfacl.html>

our system call interface is documented here:

<http://acl.bestbits.at/man/kacl.html>

We are currently working on improving the kernel ACL code (improved ACL cache,
filesystem independent ACL functions). All the discussions about Linux ACLs are
archived at <http://acl.bestbits.at/acl-devel/>.

I have also talked to Jim Meyering, the maintainer of the GNU fileutils. There
is a patch to fileutils-4.0 that adds ACL support for Solaris and Linux, but
it's not integrated yet with the fileutils distribution. It uses the system
calls directly, rather than the Draft 17 library.

See <http://acl.bestbits.at/pre/fileutils-4.0-acl-0.5.6-pre22.patch.gz>.


Regards,
Andreas

------------------------------------------------------------------------
 Andreas Gruenbacher, a.gruenbacher at computer.org
 Contact information: http://www.infosys.tuwien.ac.at/~agruenba
To Unsubscribe: send mail to majordomo at cyrus.watson.org
with "unsubscribe posix1e" in the body of the message