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

[Robert Watson]

On Mon, 12 Feb 2001, Casey Schaufler wrote:

> Robert Watson wrote:
> > 
> > Just to throw some more fuel on the fire: returning EOPNOTSUPP would be
> > nice for situations where a file system doesn't offer protection (ISO 9660
> > cd file system, for example) and you'd like to report that fact to the
> > application without attempting to non-sensically emulate ownership and
> > permissions for the object.  The ability to return EOPNOTSUPP legally
> > would mean that file systems (such as AFS, SMBfs, NFSv4, ...) would not
> > have to emulate permission/POSIX.1e ACL semantics with very poor side
> > effects.  In any of these cases, either the burden of handling failure is
> > placed on the application, or the file system masks the failure.  I'd
> > rather see explicit failure than poorly masked failure..
> 
> I believe that acl_set_file() ought not to pretend to work if it does
> not. On Irix we return ENOSYS, as that was the required return in one of
> the DRAFTS. 

Hmm.  Here's what currently happens on FreeBSD 5.0-CURRENT with ACL
patches slapped in, and when addressing native UFS file systems:

1) If UFS_ACL is not defined in the kernel config file (that is, ACL
   support is not compiled in for UFS file systems), then the ACL VOP's
   will always return EOPNOTSUPP. 

2) If UFS_ACL is defined in the kernel config file (support is compiled
   in), but is not enabled for the current file system (i.e., appropriate
   extended attributes don't exist, or extended attribute support is
   not available), then acl_get_file() returns an ACL based on the
   available permissions, but acl_set_file() returns EOPNOTSUPP in all
   cases (even when the ACL could be mapped to a base set of permissions)

3) If UFS_ACL is defined in the kernel config file (support is compield
   in), and appropriate extended attributes are configured and enabled for
   the target file system, acl_get_file() and acl_set_file() both work
   as defined.

So if you try the three cases, the following occur:


Case	getfacl	setfacl
1	fails	fails
2	works	fails
3	works	works

In each case, "fails" corresponds to EOPNOTSUPP.  For other file systems
not providing an ACL implementation for any VOP (get, set, check),
EOPNOTSUPP is returned.  At some point in the future, what will probably
happen is that UFS_ACL will not need to be compiled in, since it always
will be available, so it will boil down to cases (2) and (3).  (2) when
ACLs are not enabled for a file system (by whatever mechanism, probably a
superblock flag), and (3) when they are.  As it currently stands, this
meets your requirement that setfacl fail when ACLs are not understood by
the file system, but allows getfacl to produce a useful result, and
consistent with getfacl(1), although it's possibly arguable that the
implementation of that useful result should be in libposix1e and not in
kernel.  The (1) case from above will still apply for file systems not
supporting ACLs in any form.  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.

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