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

[Robert Watson]

On Tue, 13 Feb 2001, Casey Schaufler wrote:

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

I would agree that "Not good" could be a correct evaluation of the
situation.  That is, this is something I'd be willing to change, and would
see the result as arguably more consistent.  I.e., "Either a file system
supports ACLs or it doesn't.  There is no try."  However, the result of
changing this is that getfacl(1) now needs to know how to turn a
permission set into an ACL due to POSIX.2c's requirement that such an
emulation occur.  This is not a big problem.

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

Hmm.  My reading of POSIX.1e D17 was always that the access ACL was
considered to be a superset of the the base permissions, and as such the
permissions would always be returned as part of the access ACL.  On a file
system that used POSIX.1e ACLs exclusively (i.e., no distinction is made
between permissions and ACLs), it would be desirable to *only* use the
acl_* calls to manage protections, rather than having applications
potentially use multiple interfaces.  So I should clarify the current
behavior in my implementation: as such, the access ACL is *always*
defined, as the base ACL (permissions) are always defined.  For
ACL_TYPE_DEFAULT, where it is possible for the ACL not to be defined, an
ACL with zero entries is returned (per POSIX.1eD17).

This permits applications to purely use the acl_{get,set}_{fd,file}()
interface to manage base DAC protections, which is a benefit in my mind.
Otherwise all the logic for relation permissions and ACL components has to
live in the kernel *and* in userland.

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

Right now, based on whether or not the are three entries in the access
ACL, if acl_get_file() returned non-NULL.  I wouldn't claim that that is
an ideal answer, but it's consistent with the idea that stat() returns a
subset of the true DAC protections, whereas acl_get_{fd,file} return the
complete picture for a POSIX.1e-enabled ACL file systems.  One thing I
have been considering is grabbing an extra bit in the st_mode field to
indicate whether or not there are "additional/alternative discretionary
protections" on a file, which could then be interpretted by strmode(3),
which apparently already knows about the +. 

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

Fine. :-)

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