From nobody Sat Aug 03 02:34:11 2024 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4WbRc10lXPz5RjRt for ; Sat, 03 Aug 2024 02:34:25 +0000 (UTC) (envelope-from khng300@gmail.com) Received: from mail-pl1-x62b.google.com (mail-pl1-x62b.google.com [IPv6:2607:f8b0:4864:20::62b]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4WbRc02YNCz48Wk; Sat, 3 Aug 2024 02:34:24 +0000 (UTC) (envelope-from khng300@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pl1-x62b.google.com with SMTP id d9443c01a7336-1fb3b7d0d56so50233785ad.1; Fri, 02 Aug 2024 19:34:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1722652462; x=1723257262; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=HuXZAh9r2k6BiRXmdqa/NQSbCo6244Rb4rxDQLB2lw8=; b=SIUBc0gmSPmxNx86xCbkr3rYqq2CwlseFnwIANS9T4lM0bqr+Z66wF7wVO/fiqVxwr vrc32hASyShTVfBfQb6OI41a9nUv4QcbR3ZxM/KOaqRT3JCpZH3q8j/6akyLlO028cXJ IsGfkhKcGZ6NHWxGGQu5QwsdTm2RMC5nYv4ifUl2my4LWyAxwwEpxRxTPek05O/Vt25k JZhSDXdu/h+ZsrwZpe4gHMex/ZOPKllw2H75nf1FVfcxzh41If4KdWQ/mOUGzyCTseI8 qdL4l1BqJH5LGXXJf1Y7w9rHbdk/3ij8b6IfcibY6k5h9wWqK+n7niyPGtaG61kJWvu3 jOMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1722652462; x=1723257262; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=HuXZAh9r2k6BiRXmdqa/NQSbCo6244Rb4rxDQLB2lw8=; b=Adx0wy55P9H5ciMMw8JVLjBGWgUP+aoRHXs+fFbxyBt2++DVedUvUaep+SPcuJOFyG sdxnyhpN460Hn3WFOAeq0UT5jy7z6HENNp02QH32Tj3AhlFTqZoxkO8vUbdkrF6sB13e 8/6aeRfJjqnrY+FtEJkJj/BeptovHPW10wMNVekNPYzGPmuGNqI8jJ+xctKTUFC+JSqx XkDWJZo9B9RjDmDdGQ4tiQ6YJLdmCtG99PFIb6y2g2atojqlbIc0LxtcFjo/TiZzqteY Jmhu1di5ffTIjcOLxDkyb1iuu/9lqiwILktXZfyU7Mkt2Oei07iamCAeuHgSi7I3Eeh/ CncQ== X-Gm-Message-State: AOJu0YxFBqtOJC7A01DH2WcFEOIJ+YR8Z+E7FpQPmnKGRRS/irk76sVs i0O2mhoN1/ZW6Yuq8X98oQV2+3PemvFblOyUKaQzWq9fQmIzU9WXiEi/EcnriRqHk9WJFg7OVvh 6GF+BmbzJ2Mfu7tOFApuAM7DSwt+Hfg== X-Google-Smtp-Source: AGHT+IEYddWVzR7bjsw22P6Bs21ha4IXG3eG7AqbP/KSp1cyxE3NXcv9jzUs9/lMQzra9LiUx5dQR5GG+XAFLB1PJuo= X-Received: by 2002:a17:903:2288:b0:1fd:7664:d870 with SMTP id d9443c01a7336-1ff574a9a5dmr62757285ad.51.1722652461912; Fri, 02 Aug 2024 19:34:21 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org MIME-Version: 1.0 References: In-Reply-To: From: Ka Ho Ng Date: Fri, 2 Aug 2024 22:34:11 -0400 Message-ID: Subject: Re: RFC: ACLs on fusefs To: Alan Somers Cc: FreeBSD Hackers Content-Type: multipart/alternative; boundary="000000000000105b56061ebe48c3" X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Queue-Id: 4WbRc02YNCz48Wk --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 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

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.=C2=A0 If a file system<= br> image contains files with ACL entries, the user can look them up with
getextattr, but they'll just look like a binary blob.=C2=A0 getfacl won= 't
work at all.=C2=A0 And the file system won't be able to enforce the ACL= s
during VOP_ACCESS.

Fixing this situation for posix.1e ACLs would require three things:
* A good test suite for posix.1e ACLs.=C2=A0 pjdfstest has some tests, but<= br> it's incomplete.
* An example file system to use for testing the kernel driver.=C2=A0 It
isn't sufficient for the example file system merely to support xattrs,<= br> because the file system server must also enforce inheritance of
default ACLs.
* The actual kernel support.=C2=A0 Enforcing ACLs during VOP_ACCESS must be=
done within the kernel, not the server.=C2=A0 The important parts are
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
test=C2=A0 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.=C2=A0 But is it worth our<= br> time?=C2=A0 How many real-world users would benefit?=C2=A0 Alternatively, d= oing
just the kernel support would be fairly easy.=C2=A0 That would be too small=
for GSoC.=C2=A0 But we could easily overlook important bugs if we don't= do
the other steps, too.

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

--000000000000105b56061ebe48c3--