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

[Casey Schaufler]

Robert Watson wrote:

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

Good.

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

Not good.

>    but acl_set_file() returns EOPNOTSUPP in all
>    cases (even when the ACL could be mapped to a base set of permissions)

Good.

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

Not so good. If the file has not had an ACL assigned, either
explicitly with acl_set_{file,fd}() or implicitly by a
directory default ACL, acl_get_file() ought to return NULL.



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

So how do you decide whether to put the "+" into the ls -l output?

> I prefer EOPNOTSUPP to ENOSYS ...

We only use ENOSYS because the DRAFT told us to. I do not
claim it was correct.

-- 

Casey Schaufler				Manager, Trust Technology, SGI
casey at sgi.com				voice: 650.933.1634
casey_p at pager.sgi.com			Pager: 888.220.0607
To Unsubscribe: send mail to majordomo at cyrus.watson.org
with "unsubscribe posix1e" in the body of the message