ACL implementation on FreeSBD: semantics/standards/etc

[Casey Schaufler]

Robert Watson wrote:

> 1) Scrap the POSIX.1e ACL editing library

A prudent, if mercyless act.

> This reduces portability as this means
> exposing the internals of acl_t, which in the case of FreeBSD is backed by
> a struct acl:
> 
> #define MAX_ACL_ENTRIES 32    /* maximum entries in an ACL */
> #define _POSIX_ACL_PATH_MAX     MAX_ACL_ENTRIES
> 
> struct acl_entry {
>         acl_tag_t       ae_tag;
>         uid_t           ae_id;
>         acl_perm_t      ae_perm;
> };
> 
> struct acl {
>         int                     acl_cnt;
>         struct acl_entry        acl_entry[MAX_ACL_ENTRIES];
> };

A proven ACL data format, BTW. This is exactly the same as is
used by Irix, except that MAX_ACL_ENTRIES is 25 and uid_t's
are 32 bits in Irix. Even the field names are the same.

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

Relative ACLs are to complicated by half. Sure they're handy, but
I personally prefer that security attributes be completely specified
at all times, rather than modified.

Addition to ls (Irix uses -D) is very helpful. I always decried the
POSIX group's decision to stay out of everyone else's way.

-- 

Casey Schaufler                         voice: (650) 933-1634
casey at sgi.com                           fax:   (650) 933-0170
To Unsubscribe: send mail to majordomo at cyrus.watson.org
with "unsubscribe posix1e" in the body of the message