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

[Robert Watson]

Just an update e-mail having cogitated on your comments for a bit.

On Tue, 13 Feb 2001, Casey Schaufler wrote:

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

In the upcoming acl-0.6.0 release, UFS file systems without ACLs enabled
will now return EOPNOTSUPP when acl_get_file() is pointed at any of its
files/directories.  getfacl(1) will be updated to perform a stat()->ACL
conversion when it gets EOPNOTSUPP.

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

I responded to this comment in my last e-mail to you, and haven't heard
back on your further thoughts on the matter.  I'm still of the opinion
that acl_get_file() should return an ACL corresponding to the base file
permissions in the event that an extended ACL is not present.  Similarly,
that a request for a default ACL not present should return a zero-length
ACL in the manner described in POSIX.1e.  I'll leave this behavior at is,
but welcome your comments :-).

> > 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 was originally hoping to grab a bit out of mode_t, but since it's 16-bit
on FreeBSD, we're all out of bits.  As such, I'm currently sticking with
the substantiall more expensive acl_get_file() operation and the count of
the number of entries.

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

Sounds good to me.  Generally, ENOSYS on *BSD is reserved for situations
where a non-present syscall in the API was invoked, and the result is a
Signal From the Gods telling the process to go away, unless it's Really
Sure.  We'll stick with EOPNOTSUPP for the time being.

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