From nobody Fri Aug 02 23:58:13 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 4WbN842CV1z5RRmc for ; Fri, 02 Aug 2024 23:58:28 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-vk1-f174.google.com (mail-vk1-f174.google.com [209.85.221.174]) (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 4WbN830cgNz4kSy for ; Fri, 2 Aug 2024 23:58:27 +0000 (UTC) (envelope-from asomers@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=freebsd.org (policy=none); spf=pass (mx1.freebsd.org: domain of asomers@gmail.com designates 209.85.221.174 as permitted sender) smtp.mailfrom=asomers@gmail.com Received: by mail-vk1-f174.google.com with SMTP id 71dfb90a1353d-4f524fa193aso2045531e0c.0 for ; Fri, 02 Aug 2024 16:58:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1722643105; x=1723247905; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=20mU2lwdAIqGs7yMFbseysQkl6IYMdffs4Udn8UU7JE=; b=hzQW0KwlOX+ky4WhqSrYefVW8BRB25BgLE2co0KclG4pK06nJyOsOBxVR9+dvpm1NN M07RS3ZnhhKpspAnmpaQp1FMf8x2JbyhZSCTx6bS+oviGBAVhwpShFgHxwuYeefjd7Uq iOGTgJNNC7lyxSXTfh8ciOws0IAfMwRISGnErddGP5mbhIde9msy/PpcHH/4nFMTam2S l9m5t0dtdQ2BlolipYlNTG3M2MgXFW/XO/xRLFy+nKmSa75QqgVR4zyHbgyZkXJrsoQK qa+JkSKRT+Yb+ncImpR1LouurKCfwEJ9VjqUeFPEDyrFFFjghiJxL7b1PRXRIvUDbhS7 GPxw== X-Gm-Message-State: AOJu0Yxws71dMCw4dB66THX9MbVJGHBf6UrEQObt8h4fRUevwMPTqb27 kRmZvud1snDOhihkm3gp2kAAMiryKeyMAcXIwjTfceOt7QoU0OCfcEhj1IRE6TU3J2KOHg6mH2l qvtrtXyxShftJoCf7yvbx4J86DU3H6w== X-Google-Smtp-Source: AGHT+IECdBdQBrU95k92lq7XFMqQjyI72b58uzgGs9QuUjzq9Eum5iRF2x0hrFIGqD6yALe82nT0RwOWTggJgVKc5n0= X-Received: by 2002:a05:6122:3288:b0:4f5:24e0:26d4 with SMTP id 71dfb90a1353d-4f89c06b348mr5481078e0c.1.1722643105144; Fri, 02 Aug 2024 16:58:25 -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 From: Alan Somers Date: Fri, 2 Aug 2024 17:58:13 -0600 Message-ID: Subject: RFC: ACLs on fusefs To: FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.44 / 15.00]; NEURAL_HAM_SHORT(-0.99)[-0.986]; NEURAL_HAM_LONG(-0.98)[-0.978]; NEURAL_HAM_MEDIUM(-0.58)[-0.577]; FORGED_SENDER(0.30)[asomers@freebsd.org,asomers@gmail.com]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; MIME_GOOD(-0.10)[text/plain]; DMARC_POLICY_SOFTFAIL(0.10)[freebsd.org : SPF not aligned (relaxed), No valid DKIM,none]; TO_DN_ALL(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; RCPT_COUNT_ONE(0.00)[1]; MISSING_XM_UA(0.00)[]; FREEFALL_USER(0.00)[asomers]; FREEMAIL_ENVFROM(0.00)[gmail.com]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; FROM_NEQ_ENVFROM(0.00)[asomers@freebsd.org,asomers@gmail.com]; RCVD_COUNT_ONE(0.00)[1]; R_DKIM_NA(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.221.174:from]; TO_DOM_EQ_FROM_DOM(0.00)[]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; RCVD_IN_DNSWL_NONE(0.00)[209.85.221.174:from] X-Rspamd-Queue-Id: 4WbN830cgNz4kSy 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?