From nobody Sat Aug 03 22:53:39 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 4Wbyg31HSJz5RVDf for ; Sat, 03 Aug 2024 22:53:51 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from www121.sakura.ne.jp (www121.sakura.ne.jp [153.125.133.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Wbyg23jR1z4LY1; Sat, 3 Aug 2024 22:53:49 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Authentication-Results: mx1.freebsd.org; none Received: from kalamity.joker.local (123-1-21-232.area1b.commufa.jp [123.1.21.232]) (authenticated bits=0) by www121.sakura.ne.jp (8.17.1/8.17.1/[SAKURA-WEB]/20201212) with ESMTPA id 473Mrd9f042178; Sun, 4 Aug 2024 07:53:39 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dec.sakura.ne.jp; s=s2405; t=1722725619; bh=d5Sof0pfDlzTA+ACZ4f47a183iqJB+F6FQyVapNR+1E=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=KrTtjxB+04k2K0/bHuGfvP/RSIiD+6RXDHz2ci6b1uOkSdcM+zK9jdIULgeM2e2GG NWZRdhXh1pp0Q5/Bu9QpO5WGFkLodtORdaqCcidF6EkmappIxDkxUtoXGmLqaCePzO 23q+GzGoTsV1CEgPeDx68ChirzcSporE2VnU2SLI= Date: Sun, 4 Aug 2024 07:53:39 +0900 From: Tomoaki AOKI To: freebsd-hackers@freebsd.org Cc: Alan Somers , Ka Ho Ng Subject: Re: RFC: ACLs on fusefs Message-Id: <20240804075339.740897064c00d731b102e1d9@dec.sakura.ne.jp> In-Reply-To: References: <20240803131134.20f61fe590d1929a1733abc3@dec.sakura.ne.jp> Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.1) 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 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit 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:7684, ipnet:153.125.128.0/18, country:JP] X-Rspamd-Queue-Id: 4Wbyg23jR1z4LY1 Resent, as this didn't sent from ML system for more than 4 hrs. To be sure, readded original recipients. Agreed. So options a) and b) I described should not be applicable at least for now. Although I've described (just for completeness) option b), it should not be accepted. Could cause severe and unrecoverable problems in the wild. (Not noticing about lost EAs/ACLs.) For option c), maybe we must decide what error to be returned when underlying filesystem does not support storing requested EAs/ACLs to notify that the user should use any kind of archivers which supports storing wanted EAs/ACLs, or copy/move to different filesystem that support them. Maybe any of 13 EACCESS, 22 EINVAL, 45-47 E*NOSUPPORT, 79 EFTYPE, 87 ENOATTR? 87 seems to fit for EAs, but not for ACLs. On Sat, 3 Aug 2024 08:59:15 -0600 Alan Somers wrote: > Storing ACLs in hidden files is beyond the scope of what I had in > mind. That would be an entirely new challenge. And it wouldn't be > possible to do it correctly, because the file system server is still > responsible for the inheritance of default ACLs. For the present, all > that I have in mind is file systems that can store ACLs natively. > > On Fri, Aug 2, 2024 at 10:11〓PM Tomoaki AOKI wrote: > > > > I'm not understanding the implementation of fusefs, but possible > > problem to be considered is the levels of suuports for EAs and ACLs of > > each implemented filesystems. > > > > What I recall is the implementation of EAs on OS/2. > > IIRC, HPFS natively supported EAs and WPS/Presentation manager-specific > > attributes (like registry on recent Windoze). > > To support both on FAT, OS/2 used 2 hidden system files named > > EA_DATA.SF and WP_ROOT.SF respectively. > > > > What's needed to consider would be: > > a) Store EAs and ACLs on hidden system files with fixed name > > on the root directory of filesystems which don't support > > EAs and/or ACLs. > > > > b) Silently ignore unsupportd attributes/ACLs and store supported > > ones only without returning error. > > > > c) Error out if any of unsupported attributes/ACLs are specified. > > > > Maybe b) would be fatally problematic, as admins who don't understand / > > don't want to learn about implementations in deep would missingly > > believe every attribs/ACLs are completely and flawlessly stored even on > > filesystems which does not support them. > > > > a) would be best, if ALL FUSEFS GUYS ON OTHER OS'es agree with the > > specific filename and its internals, promissing to implement theirs as > > such, too. Unfortunately, maybe not realistic, unless ISO/IEC or POSIX > > mandates the support and standardize the name and formats of special > > file. > > > > > > On Fri, 2 Aug 2024 22:53:05 -0400 > > Ka Ho Ng wrote: > > > > > Having said that, I am not sure if the FUSE protocol itself is extensible > > > to accommodate the needs to directly implement the counterparts of our > > > existing ACL syscalls. Otherwise XATTR tunneling for both NFSv4 and POSIX > > > 1.e on FUSE might be the only way to go. > > > > > > May I know if there're any users of the XATTR approach besides the > > > e2fsprogs/fuse2fs implementation of the EXT4 filesystem? > > > > > > Ka Ho > > > > > > On Fri, Aug 2, 2024, 22:34 Ka Ho Ng wrote: > > > > > > > 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? > > > >> > > > >> > > > > > > -- > > Tomoaki AOKI -- Tomoaki AOKI