acl_get_file() -- failure mode when ACLs not available on file system?

[Robert Watson]

Most of the ACL implementations on UFS-like file systems I have looked at
allow for the possibility that ACLs might be available on some file
systems, but not others.  My question has to do with behavior of the
acl_{get,set}_{fd,file}() library calls, as well as the {get,set}facl
utilities.  How should these fail in an environment where ACLs are not
available?  To what extent should they attempt to emulate ACLs?

For acl_get_{fd,file}(), it seems to me that there are at least two useful
options:

1) The calls can return EOPNOTSUPP to indicate that they do not support
   the ACL interfaces, or EINVAL if they support the ACL interface, but
   the requested ACL type is not defined. 

2) They can convert native UNIX file permissions for the file into a
   POSIX.1e ACL in the natural manner: file owner becomes ACL_USER_OBJ,
   group becomes ACL_GROUP_OBJ, and other becomes ACL_OTHER.

For acl_set_{fd,file}(), much the same applies:

1) EOPNOTSUPP or EINVAL

2) Map ACLs into permissions, and return EINVAL if there are more than the
   base ACL defined, as permitted by a potentially low limit on
   pathconf{_POSIX_ACL_PATH_MAX} (3).

The spec for getfacl(1) already indicates how to handle that ACLs are not
available for the object: they are to be emulated using the base file
permissions.  The setfacl(1) spec doesn't appear to specify the desired
behavior.  The getfacl(1) emulation can be done at many places in the
stack -- it can be emulated by getfacl, it can be emulated in
acl_get_{fd,file}(), it can be emulated in the system call layer, by the
file system, etc.  If it is to be emulated, it may be that it is desirable
to emulate it below the VFS layer in the file system, where the file
system can perform the best mapping from its native DAC mechanism (be it
POSIX permissions, or whatever).

As to my preferences concerning possible answers--I'm fine with emulation,
I suppose, but if so, I'd want it to be done behind the scenes in
acl_get_file() and friends, so that getfacl doesn't grub around inside the
ACLs any more than it currently has to (almost none).  As to setfacl -- It
would be nice if the utility could be more specific about how it is the
ACL is not appropriate via EINVAL, as EINVAL is hard to interpret.  If
emulation is going to occur, I'd again like it to occur behind the scenes.
The nice thing about return EOPNOTSUPP for both of these is that it allows
the caller to fall back on normal permission mechanisms.  On the other
hand, maybe this is not so nice...  It's easy for me to arrange a default
VOP_GETACL / VOP_SETACL / VOP_ACLCHECK set of functions implemented for
all file systems that map into native permissions for when the file system
doesn't have its own ACL support.  In any case, adding EOPNOTSUPP to the
list of acceptable errors for the ACL calls to return might make sense as
it does apply to most file system calls.

Robert N M Watson             FreeBSD Core Team, TrustedBSD Project
robert at fledge.watson.org      NAI Labs, Safeport Network Services

To Unsubscribe: send mail to majordomo at cyrus.watson.org
with "unsubscribe posix1e" in the body of the message