ACL implementation on FreeSBD: semantics/standards/etc

[Robert Watson]

On Mon, 17 Jan 2000, James Buster wrote:

> Robert Watson wrote:
> > 1) Scrap the POSIX.1e ACL editing library, limiting interfaces to
> > allocating, freeing, validating, converting, getting, and setting
> > of ACLs.
> 
> That's the route we chose in Irix. The Posix ACL editing functions
> are not very useful; acl_from_text() is sufficient for nearly every
> case.

Good point--I had not thought of this :-).  The only other reason I can
think of is backup utilities--do you intend for them to use text-form ACLs
internally? (this is fine, I was just curious :-).

> > I found the editing library counter-intuitive and problematic to
> > implement given the ACL storage format I chose.  This reduces
> > portability as this means exposing the internals of acl_t
> 
> I disagree. If the only way you can create an ACL from user input
> is acl_from_text(), then there should be no need to expose the
> internals of acl_t.

I'm not clear that it wouldn't be desirable for some wiz-bang graphical
file manager to be able to manage the ACL contents.  However, I think that
the POSIX.1e D17 interface is not the ideal way to do this, if there is to
be such an interface. 

> > which in the case of FreeBSD is backed by a struct acl:
> 
> They look just like Irix ACLs :-)

Leaving aside the constant name, and some type foo relating to number of
bits for various types, apparently.

> > I implemented the following POSIX.1e interfaces:
> 
> Pretty much the same set as Irix, except for acl_calc_mask(),
> which never seemed very useful.

This was a first step into implementing them all before I gave up.  You're
right--I might as well strip it out of the library and just have it in
setfacl.

> > I introduced the following non-POSIX.1e interfaces:
> > int     acl_delete_def_fd(int filedes);
> 
> Personally, I think the right interface is
> 
> int acl_delete_fd(int fd, acl_type_t type)
> int acl_delete_file(const char *path, acl_type_t type)

Sounds good to me.  If we're allowing multiple ACL semantics to coexist,
we should allow for deleting ACLs of various sorts.  Since we're still not
in code freeze for FreeBSD 4.0, I'll make this change and back the
POSIX.1e routines onto it.

> > 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);
> 
> These seem redundant. If you want to see if an acl is valid, do
> an acl_get_*() followed by acl_valid(). Besides which, ACLs on
> the filesystem should be presumptively valid, since acl_set_*()
> should never allow an invalid ACL.
> 
> The right function to see if an ACL may be applied to a file
> is pathconf(_PC_ACL_ALLOWED)/fpathconf(_PC_ACL_ALLOWED).

The reason for checking the validity of an ACL for a particular file is
that different file systems may have different definitions of "valid".
For example, a valid ACL for AFS is unlikely to be valid for
POSIX.1e-enabled FFS, but it would be nice to use the same interface.  I
realize this is potentially confusing for the user, but that's something
the administrator of the machine has already accepted by permitting
different ACL types on different file systems :-).

As you point out, ACLs coming from a file system should always be valid.
There's some question as to whether acl_valid() is ever necessary...

  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