ACL implementation on FreeSBD: semantics/standards/etc
robert at cyrus.watson.org
Mon Jan 17 19:36:36 GMT 2000
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,
int extattr_set_file(char *path, char *attrname, struct iovec *iovp,
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
More information about the posix1e