Re: RFC: ACLs on fusefs

I would rather see the support of XATTR and NFSv4 ACL being two orthogonal
things, just like how it's being worked out on ZFS.

On Fri, Aug 2, 2024, 19:58 Alan Somers <asomers@freebsd.org> wrote:

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