Samba ACL's and FreeBSD

[Robert Watson]

On Mon, 9 Apr 2001, Jeremy Allison wrote:

> As POSIX ACL's are not a firm spec (ie. never got finalised)  I didn't
> think it too onerous to require it for Samba ACLs. 
> 
> Does anyone know why this functionality (asking the "is this value in
> this permset" question) was removed from the POSIX draft ? 

There's a POSIX.1e mailing list, posix1e at cyrus.watson.org, which you can
subscribe to by sending mail to majordomo at cyrus.watson.org.  The draft
gets discussed there fairly frequently, and it seems to have been a
successful vehicle for the discussion of what should and shouldn't be
done.  There has also been a workshop hosted by SGI on making sure that
POSIX.1e features (such as capabilities) are properly implemented and
extended.  So while it's not a firm spec, there is life.  Chris just
posted a question about the acl_get_perm() interface to the list; if you
feel it's an important interface that *should* have been part of the spec,
it's worth bringing it up there.  Among other people, we have the final
draft editor on the mailing list, and he can often answer questions of
intent, as well as explain the rationale for decisions made that result in
draft changes.

> The ACL API's on all versions of UNIX are so messey anyway (only Linux
> as far as I know has a "true" POSIX ACL patch) that as far as Samba is
> concerned, I really don't care :-). 

FreeBSD 5.0-RELEASE (due out later this year) will implement POSIX.1e
ACLs, Capabilities, and a superset of the MAC interface.  So far, it
implements pretty much all of the POSIX.1e ACL editing API as of draft 17
(a few remaining bits need to be committed by Chris to finish it off).  We
have been pretty careful about clearly identifying any non-spec interfaces
by adding "_np" to the end of the name of the function.  For example, in
addition to providing the spec acl_get_fd() call, we've extended
acl_get_fd()  to as acl_get_fd_np() to allow the specification of an
acl_type_t when retrieving an ACL from a file descriptor.  This was
necessary because BSD supports obtaining file descriptors on directories. 

While we would not necessarily be opposed to implementing the call you
require, if it's not in draft 17, I think we'd really prefer to add an _np
to the end to indicate that it is a non-portable call (not in the final
version of the spec).  Discussion of the interface on the POSIX.1e mailing
list could clarify that its removal was an error, and that it was meant to
be there:  if so, we'd just introduce it named normally.  If it was
removed for a good reason, we'd rather not introduce it.  :-)  I'd invite
you to get involved in the mailing list (there's an archive available via
www.securityfocus.com) and chat with various developers who have written
the spec and implemented the interfaces, especially if you feel the last
published draft, D17, doesn't meet your needs.

We've tried to stick to the spec wherever possible, in the hopes of
maximizing the chances of applications working in a portable manner across
platforms.  Everyone admits the draft was far from perfect, but it
represents a strong starting point, and a lot of thought went into it,
taking into account the needs of a number of implementations. 
Implementing a "libposix1e" for various almost-POSIX.1e platforms (such as
the Solaris implementation, which is many ways almost POSIX.1e) might be a
good way to make this more useful. 

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