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

[Andreas Gruenbacher]

On Mon, 12 Feb 2001, Robert Watson wrote about the return value of the ACL
system calls and ACL library functions...

On Linux, the EA/ACL system calls and library functions work as follows:

If extended attributes are not compiled into the kernel, the system calls
return ENOSYS. If they are compiled in, but the filesystem doesn't
support them (because it is not able to, or EA's have been disabled for
this filesystem), the result is ENOTSUP (Operation not supported).

If ACL's are enabled on a fileystem, the EA syscalls return an ACL if an
_extended_ ACL is defined, or ENOATTR (No such attribute) otherwise.

The ACL library functions acl_get_{file,fd}() tries to return a reasonable
ACL in all cases. In case of ENOSYS, ENOTSUP or ENOATTR, they synthesize
an access ACL from the file mode permission bits, and use an empty ACL for
the default ACL.

The acl_set_{file,fd}() function behaves similarly: If the system calls
return ENOSYS or ENOTSUP, these functions check whether the ACL entirely
fits in the file mode permission bits. If it does, a {f}chmod() is
done. Otherwise, acl_set_{file,fd}() fail.

I have separate library functions to check whether a file has an extended
ACL. They are called acl_extended_{file,fd}(). This is because calling
acl_get_file(<<ACL_TYPE_ACCESS>>), acl_get_file(<<ACL_TYPE_DEFAULT>>) and
checking whether the ACL has no more than three entries and the default
ACL is empty is rather expensive but is required to be pretty quite for
ls.

The ACL library API is specified in a way that an efficient _and_ fully
compliant implementation is not possible. Checking whether an ACL has no
more than three entries is particularly bad. One first has to create the
full ACL object, with individual ACL entry sub-objects in the first place.
Then there's no way to check how many entries an ACL has; the only
mechanism the library includes is to iterate the ACL and count the ACL
entries. (Hence in my implementation there's also an incompatible function
acl_entries() that returns the number of entries in the ACL).


> [...] I prefer EOPNOTSUPP to ENOSYS since ENOSYS would imply that the
> call is not part of the ABI, which it is, whereas EOPNOTSUPP means
> that the target object (file/directory/whatever) doesn't support the
> operation.

Me too, but I'm actually using ENOTSUP instead of EOPNOTSUPP (ENOSYS was
defined in DS17). Actually---since ENOTSUP isn't currently defined in
Linux, it currently is an alias to EOPNOTSUPP anyway...


Best,
Andreas.

------------------------------------------------------------------------
 Andreas Gruenbacher, a.gruenbacher at computer.org
 Contact information: http://www.bestbits.at/~ag/

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