RFC: ACLs on fusefs

From: Alan Somers <asomers_at_freebsd.org>
Date: Fri, 02 Aug 2024 23:58:13 UTC
TLDR;
how useful would it be if fusefs(4) could support ACLs?

The current state of fusefs is that while it has full support for
extended attributes, it lacks any support for ACLs.  If a file system
image contains files with ACL entries, the user can look them up with
getextattr, but they'll just look like a binary blob.  getfacl won't
work at all.  And the file system won't be able to enforce the ACLs
during VOP_ACCESS.

Fixing this situation for posix.1e ACLs would require three things:
* A good test suite for posix.1e ACLs.  pjdfstest has some tests, but
it's incomplete.
* An example file system to use for testing the kernel driver.  It
isn't sufficient for the example file system merely to support xattrs,
because the file system server must also enforce inheritance of
default ACLs.
* The actual kernel support.  Enforcing ACLs during VOP_ACCESS must be
done within the kernel, not the server.  The important parts are
already in sub_acl_posix1e.c.  The fusefs test suite would need a few
more test cases for VOP_GETACL and VOP_SETACL, but wouldn't need to
test  any of the fancy stuff, like inheritance or enforcement during
access.

Fixing the situation for NFSv4 ACLs would require the above, and also
a small extension to the fusefs protocol.

All of the above might make a good GSoC project.  But is it worth our
time?  How many real-world users would benefit?  Alternatively, doing
just the kernel support would be fairly easy.  That would be too small
for GSoC.  But we could easily overlook important bugs if we don't do
the other steps, too.

So my question is: is this worthwhile?  Does anybody know of a
real-world workload that would benefit?