ACL implementation on FreeSBD: semantics/standards/etc

[James Buster]

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.

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

> which in the case of FreeBSD is backed by a struct acl:

They look just like Irix ACLs :-)

> I implemented the following POSIX.1e interfaces:

Pretty much the same set as Irix, except for acl_calc_mask(),
which never seemed very useful.

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

> 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).
-- 
Planet Bog -- pools of toxic chemicals bubble under a choking
atomsphere of poisonous gases... but aside from that, it's not
much like Earth.
To Unsubscribe: send mail to majordomo at cyrus.watson.org
with "unsubscribe posix1e" in the body of the message