From nobody Sat Mar 29 16:15:10 2025 X-Original-To: freebsd-current@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 4ZQ2YH4Gvdz5rgSh for ; Sat, 29 Mar 2025 16:15:15 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: from mail-il1-x133.google.com (mail-il1-x133.google.com [IPv6:2607:f8b0:4864:20::133]) (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 4ZQ2YG4RjLz3s2D for ; Sat, 29 Mar 2025 16:15:14 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=hardenedbsd.org header.s=google header.b=Ba+OUyHk; dmarc=none; spf=pass (mx1.freebsd.org: domain of shawn.webb@hardenedbsd.org designates 2607:f8b0:4864:20::133 as permitted sender) smtp.mailfrom=shawn.webb@hardenedbsd.org Received: by mail-il1-x133.google.com with SMTP id e9e14a558f8ab-3d589227978so9961545ab.1 for ; Sat, 29 Mar 2025 09:15:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardenedbsd.org; s=google; t=1743264913; x=1743869713; darn=freebsd.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=mRKWg1HF2FbwyfoNIOV9V4TWZ5CKSL2zgYHJkPuXsUo=; b=Ba+OUyHkohYIflmimzaCj4Gk8BTQlHOUxeVf6JtH+i/qWbNKaa1VqM0gQ3UeQMWh2k lvp9fgSFOrOhiBN443MrQXQK/5/piJpWX0MpXoDQC4U2byEX7Rg6MAzYy/LRZBDULO05 9ktn4PxGo2VPZqp6Gv8xwxSZrAeJX0+u3YbgFtVngfOGztuMK1Wg1NmNv3PMQG2lLRzC VipoxLvecwjc8CM7TgLfNGZvnsCIlZgOgM1Wnz/ga5WNYGYZ3e/JpKu/TjId8NZyqoEJ f8S8/N2J5TNSSeflN6kemakqFCj3JNO8D80g7LMGh66xh8VJkwrSuGmH2a1wCUsqJrb2 4P8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1743264913; x=1743869713; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=mRKWg1HF2FbwyfoNIOV9V4TWZ5CKSL2zgYHJkPuXsUo=; b=HEJZgdIqCaYZ3V4HpbpGF0ucVRTf23H0tC4m667BkghpLumqqvuZV8IUvyYZpbklSd PgV7g741PYl2ic2k3RFZTJ6L3BvdcyelUG4DRjMZ/S0scyFO30IbbZLFJ0uBXZpBJ2yu i4IzAlSTG12YpYJT7parywtlp41ewcD/aEYl6yCQdX3cYz9rFy6E3mumcUYvnTiRDq/H 2rP6XNLdrcp5PBXXB9HG1aMxTzSuHENfZ4Fxmt8D4K3tRLU2Q1Jj2F7qfxnFNDNM0Glh bVU9CDxyBGKwPioaQNCPfiYd+GZMDlnxb6Nn+QlQJF7thyL+JXUC3WuKkNBuGYdiLgk6 2mKA== X-Forwarded-Encrypted: i=1; AJvYcCUq1WNNL3HDuq9cNKwwpaOJv3TWbaE7NwWr7l82yC2xOSVMYtVhU2ZaDmevGvJkxk5WYxip725HalidaPz+3bM=@freebsd.org X-Gm-Message-State: AOJu0Yzltd+yaOUv+ad2jgKyvaIAUl/BQ04BGo8jKDqqdBYoDlrBluzI 3vvoh1mBlluxIYytxt+8brPHJqrxaqF+vXlLG2qOPMIuYe7eaYUMbMbDrQLa/Az4keoj+UvJgVo U8tw= X-Gm-Gg: ASbGncuRQf3x2FGvXTChu7oc80EWi7CrOmqBevRmICpTgQlMkZd3VNBtc6Qt0bvbbbK 6VukjfNce7GrnhCGK3dsqvvSYIHdX5ucTaJ73F+bat5ovWyES8IH90J16Z1HUWbHW/M59xeq/hc BKgsJBQsNqGWgtuyMzeff1UCttoJcxgbJCLaXa2EA4G0Gq4YNglVIUoEHI/PDc7CFlWKmO0Xo0w AH+dreyHa4nzUNYnWR1DO3BGsBXfMI22Q97g42BOwi9KXcb4pKmYkZb5ScN8mHNWxRbyWzJah0s nSpH2VTFtudZDNl3ENrPf6O4gR8= X-Google-Smtp-Source: AGHT+IHXoqqn7UFIH7hQfWJhPXGqEvQNhSi42BxDaqD8UmeLDNQnzcBlozdGpJuknUQwQTXHehC3HA== X-Received: by 2002:a05:6e02:156a:b0:3d4:2ea4:6b87 with SMTP id e9e14a558f8ab-3d5e0a10f4amr27493555ab.11.1743264913171; Sat, 29 Mar 2025 09:15:13 -0700 (PDT) Received: from mutt-hbsd ([2001:470:4001:1::95]) by smtp.gmail.com with ESMTPSA id e9e14a558f8ab-3d5d5ae9dbbsm10383835ab.52.2025.03.29.09.15.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 29 Mar 2025 09:15:12 -0700 (PDT) Date: Sat, 29 Mar 2025 16:15:10 +0000 From: Shawn Webb To: Rick Macklem Cc: Dennis Clarke , freebsd-current@freebsd.org Subject: Re: RFC: Solaris style extended attributes for FreeBSD Message-ID: X-Operating-System: FreeBSD mutt-hbsd 14.2-STABLE-HBSD FreeBSD 14.2-STABLE-HBSD HARDENEDBSD-14-STABLE amd64 X-PGP-Key: https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/blob/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc References: <410014e4-75a6-4923-8f84-3935cab41c31@blastwave.org> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="wqit7qhvmao6tdby" Content-Disposition: inline In-Reply-To: X-Spamd-Result: default: False [-4.72 / 15.00]; SIGNED_PGP(-2.00)[]; NEURAL_HAM_LONG(-1.00)[-0.996]; NEURAL_HAM_MEDIUM(-0.90)[-0.904]; NEURAL_HAM_SHORT(-0.72)[-0.721]; MID_RHS_NOT_FQDN(0.50)[]; R_DKIM_ALLOW(-0.20)[hardenedbsd.org:s=google]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; DMARC_NA(0.00)[hardenedbsd.org]; RCVD_TLS_LAST(0.00)[]; DKIM_TRACE(0.00)[hardenedbsd.org:+]; RCPT_COUNT_THREE(0.00)[3]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_TO(0.00)[gmail.com]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; MISSING_XM_UA(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TAGGED_RCPT(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::133:from] X-Rspamd-Queue-Id: 4ZQ2YG4RjLz3s2D X-Spamd-Bar: ---- --wqit7qhvmao6tdby Content-Type: text/plain; protected-headers=v1; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Subject: Re: RFC: Solaris style extended attributes for FreeBSD MIME-Version: 1.0 On Sat, Mar 29, 2025 at 07:35:03AM -0700, Rick Macklem wrote: > On Fri, Mar 28, 2025 at 1:31=E2=80=AFPM Dennis Clarke wrote: > > > > On 3/8/25 18:02, Rick Macklem wrote: > > > First off, I cross posted because I don't think many read freebsd-arc= h@. > > > There seems to be a nice market for Solaris style extended attributes. > > > > Hold on a moment. > > > > I have been following this discussion now for a while and I am trying to > > figure who wants this? Why? Is this a "make work" project wherein a pile > > of code and testing will needed? Where the word "pile" may mean years. > > > > > Since ZFS is already wired for them, adding the basics is pretty > > > straightforward. I am not suggesting that they should replace the > > > current FreeBSD extended attributes. > > > > > > > Well if you decide to go into NFS with xattr then you may as well dig > > into UFS with xattr also. Perhaps that would be insane however once you > > deal with ACL handling in tools like tar and ls then you will need to > > ponder UFS also. That means output similar to Solaris /usr/xpg4/bin/ls > > like so : > > > > The following example shows how to display compact ACL > > information on a ZFS directory. > > > > % ls -dV test.dir > > drwxr-xr-x 2 marks staff 2 Mar 14 10:17 test.dir > > owner@:--------------:------:deny > > owner@:rwxp---A-W-Co-:------:allow > > group@:-w-p----------:------:deny > > group@:r-x-----------:------:allow > > everyone@:-w-p---A-W-Co-:------:deny > > everyone@:r-x---a-R-c--s:------:allow > > > > The following example illustrates the ls -v behavior when > > listing ACL information on a UFS file. > > > > $ ls -v file.3 > > -rw-r--r-- 1 root root 2703 Mar 14 10:59 file.3 > > 0:user::rw- > > 1:group::r-- #effective:r-- > > 2:mask:r-- > > 3:other:r-- > > > > I see considerable differences between the FreeBSD base ls and Solaris > > ls which does handle ACL data in both UFS and ZFS. Does this need to > > be dragged onto the table along with every other file handling tool > > and system call? I see a tarpit ( no pun intended ) this opens up. > Well, the NFSv4 ACLs exist now in FreeBSD for ZFS and no one has been pus= hing > for "ls" to know how to display them. (See getfacl(1)) >=20 > ZFS also already supports extended attributes and, as above, "ls" does not > know how to display them. (See lsextattr(1), getextattr(1)...) >=20 > I do not see why commands like "ls" need to know about these things. > tar/pax is a different story, since archival of them seems necessary. >=20 > All the patches I have created does is add a different, Solaris like > syscall/KABI > for manipulating extended attributes. The patches just use code that > is already in ZFS to > handle the extended attributes as files in a directory. > ZFS currently appears to store extended attributes two ways: > "zfs set xattr=3Dsa " - For this one, small extended > attributes are stored > in some sort of storage block. If the extended attribute is too > large for the storage > block, it spills over into a file in a directory. > --> The alternate syscall/KAPI does not work and is disabled for > this property setting. >=20 > "zfs set xattr=3Don " - Also called "dir", all extended > attributes are stored > as regular files, with a directory holding their names. > --> The alternate syscall/KAPI the patches adds provides a more > direct way to access > this directory and the files that store the extended attributes. > The main advantage of this syscall/KAPI is that large extended > attributes are supported. >=20 > Since this is already how ZFS stores extended attributes, I assume > send/recv knows > how to deal with them. tar/pax will need to know the alternate > syscall/KAPI to handle > large extended attributes if this syscall/KABI is used. (The thread I > mentioned over > on freebsd-hackers@ mentions a patched version of pax/tar, but I have > not looked at it.) >=20 > Do many people need/want to handle large extended attributes? > I'd guess not, but I really have no idea what FreeBSD users use? > (I only hear about problems w.r.t. NFS, so I have no idea how many use > it without > problems.) > For NFSv4, this alternate model is supported as "named attributes". There= is as > extension to NFSv4.2 for the Linux/FreeBSD model for small extended attri= butes, > but this extension doesn't work for clients on Windows, Mac OSX or Solari= s. > As such, there is another niche market for some NFSv4 clients. >=20 > The patches are rough, but basically done. I am now in testing mode. It w= as not > exactly a "make work" project. More a "I was curious to see how easily > the Solaris > style syscall/kapi could be implemented" project. >=20 > I do not see any reason why UFS would need/want this alternate syscall/ka= pi, > since anyone wanting/needing large extended attributes could use ZFS, whi= ch > is what most managed storage will use anyhow. >=20 > In summary, other than the patches I've already done, a patched version of > tar/pax is about all I think is needed. >=20 I had added filesystem extended attribute support to libarchive, which is what FreeBSD's tar(1) is based off of. I upstreamed that, so that's taken care of. FreeBSD's tar(1) has supported extended attributes since 2020 (see libarchive PR 1409: https://github.com/libarchive/libarchive/pull/1409) > > > For those not familiar with them (I am not very familiar myself;-), > > > a Solaris style extended attribute is in a directory that hangs off > > > the file object and the entries in the directory (the attributes) can > > > be manipulated with open/read/write/lseek just like a regular file. > > > (They can be as large as a regular file, but there is no atomicity > > > guarantees.) > > > > I just, today, shutdown my last Solaris server which was a Fujitsu > > SPARC64 machine and it was draining power and making heat for a number > > of years in my life. Certainly it was using ZFS but not the ZFS that we > > can use or "zfs send" anywhere. The botched up stuff that is totally not > > compatible with OpenZFS of any flavour. This means that I had to do a > > blunt force medieval tarball backup. Nothing else would ever be usable > > for recovery. > > > > Never in the many many years of using Solaris with ZFS have I felt the > > need to drag in xattr's on people. Not once in two decades. Pretty sure > > I did some very early testing within the OpenSolaris project and can not > > recall the desperate need thereafter. > > > > So who wants this? Why? Is there some atom-splitting world changing > > reason that the extended attributes are needed in FreeBSD? Just one data point here: HardenedBSD uses filesystem extended attributes to toggle certain exploit mitigations on a per-application basis. That's why we added support to libarchive: so we can ship certain packages with exploit mitigations pre-toggled. Thanks, --=20 Shawn Webb Cofounder / Security Engineer HardenedBSD Tor-ified Signal: +1 303-901-1600 / shawn_webb_opsec.50 https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A= 4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc --wqit7qhvmao6tdby Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEA6TL67gupaZ9nzhT/y5nonf44foFAmfoHIcACgkQ/y5nonf4 4fofqQ//byGPGpoAlkeAiTXrTFhtSrJeOZG1r3hfaP7NuzZPJ9ead/Idx8MENIxV C3xJMkRragYBGj0P3+CVMuIDnNIRubCmFyXi3sNeZZqrIWRZt7F4q3FkNrFCN+MU SP0VVS1mZcWLuxWQ+d6ZAhrqhBzp6iwA6UtP3qG2FbD3Fau0y1Q11/7Vf3DYW021 1pXaPIaFTEff9VHaIpWeheWrz9kIGhn1TAucuAKLzv1L10KL+OLF9rCHEtUogMUz x5LUMzQK0h0IR73kRQDP8Sy22hHhcYIsCLw6gfMnUqEIPatBehHUL3uYkHpM7BCV JO4VhxhW+1X8nRyPwsLkP4WxKbNH8Ph+RTqu4jRVajRO9TdhzqsID+1NlRIgt9qq y4G9B7wdQJRhQNt4xgf10QwhgR6J+MpdITNENov0NBVkFrB2k4w/d3AdELrostcB 1taVpTlDPli+IV0zLjHj2cQ7kPMi9jYk7ld8/Ixa4ZghtE8K/ZBQAie3GpNn1pNY RvlPtsAEchejWRrogKUwH8A0gtraWP0mwxrZr6LnsILiHXtu9pU5Md99/KPU1WZV BRfqLZ4R1KMSoykmKF0QJp4EsX4doM++9gAtL/tP92u1gn24uaM9/FtkqLeuKccP ypviHuDMB7/6Ym2hX7gJoAb8Sg6Dyz+SC0LgrKfqLyyNGX6scF8= =52N/ -----END PGP SIGNATURE----- --wqit7qhvmao6tdby--