ACL implementation on FreeSBD: semantics/standards/etc

[Andreas Gruenbacher]

Robert Watson wrote:
> 
> 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!

Don't get scared off. The library code is very weird due to the Draft 17
requirements. Also I didn't write manual pages for the Draft 17 functions yet.

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

You've added a type parameter to acl_get_fd() and acl_set_fd(). Maybe it's
better to change the names of these functions as well.

What I had in mind was that people will expect the full library, and then find
that part of it is missing. Or they might code to the routines you propose, and
then find they differ in parameters.

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

That sounds bad.

We have discussed this issue and came to the conclusion that the userland
utilities should specify which class of ACL they want to manipulate. (This is a
syscall parameter). Posix is one class; others may be added.

User probably wants to know which type of ACL they're dealing with; there may be
cases where the same ACL is accepted but with different semantics.

I did not decide whether/how getfacl/setfacl should manipulate non-Posix ACLs.


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