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>
next in thread | previous in thread | raw e-mail | index | archive | help
--000000000000105b56061ebe48c3 Content-Type: text/plain; charset="UTF-8" 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? > > --000000000000105b56061ebe48c3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <p dir=3D"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=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Fri= , Aug 2, 2024, 19:58 Alan Somers <<a href=3D"mailto:asomers@freebsd.org"= >asomers@freebsd.org</a>> wrote:<br></div><blockquote class=3D"gmail_quo= te" style=3D"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.=C2=A0 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.=C2=A0 getfacl won= 't<br> work at all.=C2=A0 And the file system won't be able to enforce the ACL= s<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.=C2=A0 pjdfstest has some tests, but<= br> it's incomplete.<br> * An example file system to use for testing the kernel driver.=C2=A0 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.=C2=A0 Enforcing ACLs during VOP_ACCESS must be= <br> done within the kernel, not the server.=C2=A0 The important parts are<br> already in sub_acl_posix1e.c.=C2=A0 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=C2=A0 any of the fancy stuff, like inheritance or enforcement during<b= r> 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.=C2=A0 But is it worth our<= br> time?=C2=A0 How many real-world users would benefit?=C2=A0 Alternatively, d= oing<br> just the kernel support would be fairly easy.=C2=A0 That would be too small= <br> for GSoC.=C2=A0 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?=C2=A0 Does anybody know of a<br> real-world workload that would benefit?<br> <br> </blockquote></div> --000000000000105b56061ebe48c3--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANnchUbF1Pe=HcLJ%2BNTEFHB92Jv12zFZ76OJz8DD-LOGfOfOuA>