Date: Fri, 2 Aug 2024 22:34:11 -0400 From: Ka Ho Ng <khng300@gmail.com> To: Alan Somers <asomers@freebsd.org> Cc: FreeBSD Hackers <freebsd-hackers@freebsd.org> Subject: Re: RFC: ACLs on fusefs Message-ID: <CANnchUbF1Pe=HcLJ%2BNTEFHB92Jv12zFZ76OJz8DD-LOGfOfOuA@mail.gmail.com> In-Reply-To: <CAOtMX2jska_8yG0tf31nEFDQCkQODim8yLBt2qRQ4LbBVc8ZAQ@mail.gmail.com> References: <CAOtMX2jska_8yG0tf31nEFDQCkQODim8yLBt2qRQ4LbBVc8ZAQ@mail.gmail.com>
index | next in thread | previous in thread | raw e-mail
[-- Attachment #1 --] 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? > > [-- Attachment #2 --] <p dir="ltr">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.</p> <br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Aug 2, 2024, 19:58 Alan Somers <<a href="mailto:asomers@freebsd.org">asomers@freebsd.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">TLDR;<br> how useful would it be if fusefs(4) could support ACLs?<br> <br> The current state of fusefs is that while it has full support for<br> extended attributes, it lacks any support for ACLs. If a file system<br> image contains files with ACL entries, the user can look them up with<br> getextattr, but they'll just look like a binary blob. getfacl won't<br> work at all. And the file system won't be able to enforce the ACLs<br> during VOP_ACCESS.<br> <br> Fixing this situation for posix.1e ACLs would require three things:<br> * A good test suite for posix.1e ACLs. pjdfstest has some tests, but<br> it's incomplete.<br> * An example file system to use for testing the kernel driver. It<br> isn't sufficient for the example file system merely to support xattrs,<br> because the file system server must also enforce inheritance of<br> default ACLs.<br> * The actual kernel support. Enforcing ACLs during VOP_ACCESS must be<br> done within the kernel, not the server. The important parts are<br> already in sub_acl_posix1e.c. The fusefs test suite would need a few<br> more test cases for VOP_GETACL and VOP_SETACL, but wouldn't need to<br> test any of the fancy stuff, like inheritance or enforcement during<br> access.<br> <br> Fixing the situation for NFSv4 ACLs would require the above, and also<br> a small extension to the fusefs protocol.<br> <br> All of the above might make a good GSoC project. But is it worth our<br> time? How many real-world users would benefit? Alternatively, doing<br> just the kernel support would be fairly easy. That would be too small<br> for GSoC. But we could easily overlook important bugs if we don't do<br> the other steps, too.<br> <br> So my question is: is this worthwhile? Does anybody know of a<br> real-world workload that would benefit?<br> <br> </blockquote></div>help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANnchUbF1Pe=HcLJ%2BNTEFHB92Jv12zFZ76OJz8DD-LOGfOfOuA>