ACL implementation on FreeSBD: semantics/standards/etc

[Robert Watson]

On Mon, 17 Jan 2000, Casey Schaufler wrote:

> Robert Watson wrote:
> 
> > 1) Scrap the POSIX.1e ACL editing library
> 
> A prudent, if mercyless act.

:-)  I try.

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

My mailer crashed, unfortunately, or I would have included the typedef's
for the acl tags/perms:

typedef int     acl_type_t;
typedef int     acl_tag_t;
typedef mode_t  acl_perm_t;

Under FreeBSD, uid_t is 32-bit, and mode_t is 16-bit.  Since mode_t is a
rather loaded type, I may switch to int for that also...  I'm told that
IRIX uses ACL_MAX_ENTRIES instead of MAX_ACL_ENTRIES--if this is the case,
perhaps I should switch in the hopes of interoperability?  Are there many
consumers of the ACL interface directly in your environment, or does
everything go through set/getfacl?

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

Hmm.  Given this, maybe I should ship setfacl as it is...  

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

What does ls -D do?  I don't have access to an IRIX box, unfortunately.
At one point you mentinoed that IRIX backed security labels into extended
attributes also, I think.  Did you expose the extended attribute interface
in userland, and if so, might it be worth trying to be consistent between
the two operating systems in term of userland interface?  I've been using
the following syscalls:

int     extattr_ctl(char *path, int cmd, char *attrname, char *arg);
int     extattr_delete_file(char *path, char *attrname);
int     extattr_get_file(char *path, char *attrname, struct iovec *iovp,
        unsigned iovcnt);
int     extattr_set_file(char *path, char *attrname, struct iovec *iovp,
        unsigned iovcnt);

The first syscall is just there to allow mount-time initialization of UFS
extattr files to back the attributes; the remainder are the interface that
is actually useful to applications.  I debated introducing file forks to
support this stuff, but decided to go for a simpler name=value arrangement
providing atomic replacement, and atomic reading of named attributes.


  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