From nobody Wed Apr 09 16:43:25 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 4ZXpfp6252z5s2yc for ; Wed, 09 Apr 2025 16:43:30 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: from mail-io1-xd2a.google.com (mail-io1-xd2a.google.com [IPv6:2607:f8b0:4864:20::d2a]) (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 4ZXpfn7464z3tF1 for ; Wed, 09 Apr 2025 16:43:29 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=hardenedbsd.org header.s=google header.b="hFCd/ctK"; dmarc=none; spf=pass (mx1.freebsd.org: domain of shawn.webb@hardenedbsd.org designates 2607:f8b0:4864:20::d2a as permitted sender) smtp.mailfrom=shawn.webb@hardenedbsd.org Received: by mail-io1-xd2a.google.com with SMTP id ca18e2360f4ac-8616b7ad03bso8221439f.0 for ; Wed, 09 Apr 2025 09:43:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardenedbsd.org; s=google; t=1744217009; x=1744821809; 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=SNB6CTKAY3XhkZJa+eZ9kZUe2ROYXKWjkBISk1COs9I=; b=hFCd/ctKzS3bo7ZdrD/d3nXt8qBD4fbLFsZVUXrwn8WkY0dJ9ERS6gxUquGyfDA0bu AaQk9oeWihwaAndigDNFWvWG63PB60mL0TpKJjU4FaQsGIvAiPaRQJ3kt6beYJ2i5eG8 7QzfApgXRbUyRWghtH75s3yL4C2Uwxl08YerB6PMLKEL0HgQVzMT0/oJVZK1njeKoCA8 5Yg6QQ64t8pcFygaxGPXo0pn/UoKZA/rdWzRRzSZhG1nhJ3q2Zb8W+XUT7tvsSKEi7Sy ZjiQWqbW7cW5E3yVr77P+Gyi1xWN3UuFA/HlYLXviba0oALp0OGArgZ4J3Ez1ru+SxS9 4ESg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1744217009; x=1744821809; 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=SNB6CTKAY3XhkZJa+eZ9kZUe2ROYXKWjkBISk1COs9I=; b=r9BGZ2ZHnWvdTeb2B4fncf9THeO8VTbUAledweeU5KI8A1N1F++8FO+p/GUV7j56bw P7WGrvYe6cmO0Nc2lWVsQi4hk+SRFJ0HBff+sAQeekJDN8vSSYb2jfhvlLP2rTpRhOyx k/cV/HZwz+pnjusn+crOd4ql4lCBbjg1TWzIBGdwpXlMFBj+Fm125eTxqsA+W7ZEJKON sVHlsoq4CYvDKYdKWHrqsjJQigUf8pZzZgE4UJXi3ia0OITYc6kXq4zEABsS6N01zmf+ 21kTo5JdXA5DrmafLTqLBp7Cso38mVoD/3Q/UvO0zHvjZjaAmoAd8uRyrRfu9FeL0By8 pUfg== X-Gm-Message-State: AOJu0Yw5LZjkaJMLaQ8S/ookPDpZFnjYLRPeSkYkTwOpPs6c/QyXlrq1 SUhFvOek3saUJxQg5kufBRrl7mQacj4XszwhpHXKISp0/QjGRhjHY2+Jwv2ceLE= X-Gm-Gg: ASbGncunLCjZoOOjmByV9XXnM5IPznzJcwD0WUqn8vVKYIyfhlK08iBLb17U/Bpawa4 XuYJ9rBZoFxbiyiyjegfUqiOQcaWjnh0xIFhH1Vm2h1OwJnd0v6Gv31P+Q7Wuw2zQdJAKkIAgT8 KRxsQpvXtX4qLLzIIAV+hAD6S7iM+ilcfNtVutd/MSul8ttVFVwB46gK9FMC32NyBNnrv21vFWr wElcR+JPfbAMGHw0hnMIyf9oB083LfyWshY96+L3fZ4VPrdpwTO1C/9XskUXKULpgn02ZhbXwea ByniWJe4pLJSwtfbgKt0Avk= X-Google-Smtp-Source: AGHT+IHix857xsPh6mZ29TPSjY1kDzcDwQBEwuZMXHHWhVf5SBO9QydpCLbmM3LKyUg+qtpw4C3+jA== X-Received: by 2002:a05:6602:4c05:b0:85b:3885:159e with SMTP id ca18e2360f4ac-861627bb9afmr327316739f.3.1744217007525; Wed, 09 Apr 2025 09:43:27 -0700 (PDT) Received: from mutt-hbsd ([2001:470:4001:1::95]) by smtp.gmail.com with ESMTPSA id ca18e2360f4ac-861656e176csm24851039f.42.2025.04.09.09.43.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 09 Apr 2025 09:43:26 -0700 (PDT) Date: Wed, 9 Apr 2025 16:43:25 +0000 From: Shawn Webb To: Rick Macklem Cc: FreeBSD CURRENT Subject: Re: Heads Up: commit 2ec2ba7e232d just hit main 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: <2rq3bpvhclcipvgg3mo4gml7ysuzbvt6rfnzkprceumzeaeh4b@casrpprm6mgt> <4beaxy5dpajikvafxpjogcxrpyuwwicng5ln5rxbxlbzp2o2g7@ib7wo5jzlte4> 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="ggmycmozaswce6z3" Content-Disposition: inline In-Reply-To: X-Spamd-Result: default: False [-3.92 / 15.00]; SIGNED_PGP(-2.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; 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]; NEURAL_SPAM_SHORT(0.18)[0.179]; RCVD_TLS_LAST(0.00)[]; TO_DN_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; FREEMAIL_TO(0.00)[gmail.com]; RCPT_COUNT_TWO(0.00)[2]; ARC_NA(0.00)[]; DMARC_NA(0.00)[hardenedbsd.org]; DKIM_TRACE(0.00)[hardenedbsd.org:+]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; MIME_TRACE(0.00)[0:+,1:+,2:~]; 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::d2a:from] X-Rspamd-Queue-Id: 4ZXpfn7464z3tF1 X-Spamd-Bar: --- --ggmycmozaswce6z3 Content-Type: text/plain; protected-headers=v1; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Subject: Re: Heads Up: commit 2ec2ba7e232d just hit main MIME-Version: 1.0 On Sun, Apr 06, 2025 at 02:52:28PM -0700, Rick Macklem wrote: > On Sat, Apr 5, 2025 at 5:45=E2=80=AFPM Shawn Webb wrote: > > > > On Sat, Apr 05, 2025 at 05:36:07PM -0700, Rick Macklem wrote: > > > On Sat, Apr 5, 2025 at 4:43=E2=80=AFPM Shawn Webb wrote: > > > > > > > > On Sat, Apr 05, 2025 at 04:12:15PM -0700, Rick Macklem wrote: > > > > > On Sat, Apr 5, 2025 at 9:12=E2=80=AFAM Shawn Webb wrote: > > > > > > > > > > > > On Sat, Apr 05, 2025 at 08:52:06AM -0700, Rick Macklem wrote: > > > > > > > On Sat, Apr 5, 2025 at 8:50=E2=80=AFAM Rick Macklem wrote: > > > > > > > > > > > > > > > > On Fri, Apr 4, 2025 at 6:27=E2=80=AFPM Shawn Webb wrote: > > > > > > > > > > > > > > > > > > On Sat, Apr 05, 2025 at 01:04:25AM +0000, Shawn Webb wrot= e: > > > > > > > > > > On Fri, Apr 04, 2025 at 05:40:21PM -0700, Rick Macklem = wrote: > > > > > > > > > > > On Fri, Apr 4, 2025 at 10:50=E2=80=AFAM Shawn Webb wrote: > > > > > > > > > > > > > > > > > > > > > > > > On Thu, Apr 03, 2025 at 06:12:59PM -0700, Rick Mack= lem wrote: > > > > > > > > > > > > > On Thu, Apr 3, 2025 at 4:52=E2=80=AFPM Shawn Webb= wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Wed, Apr 02, 2025 at 01:51:26PM -0700, Rick = Macklem wrote: > > > > > > > > > > > > > > > The commit 2ec2ba7e232d just hit main. I do = not think it will > > > > > > > > > > > > > > > cause problems, but it is fairly large. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Man page updates will be done as separate com= mits. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hopefully this will not cause grief, rick > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hey Rick, > > > > > > > > > > > > > > > > > > > > > > > > > > > > The patch review test plan mentions a patch to = ZFS itself to support > > > > > > > > > > > > > > named attributes. Is that patch available somew= here? > > > > > > > > > > > > > The ZFS patch is currently in phabricator as D496= 54. > > > > > > > > > > > > > Feel free to review it. > > > > > > > > > > > > > > > > > > > > > > > > > > It can also be found at: > > > > > > > > > > > > > https://people.freebsd.org/~rmacklem/zfs-xattr.pa= tch > > > > > > > > > > > > > (this is a smaller diff which can be applied to a= n up-to-date main src > > > > > > > > > > > > > tree easily) > > > > > > > > > > > > > > > > > > > > > > > > Hey Rick, > > > > > > > > > > > > > > > > > > > > > > > > I applied that zfs patch, but trying pathconf(2) on= a file on a ZFS > > > > > > > > > > > > dataset with xattr=3Don (which seems to be the defa= ult) returns 0. Am I > > > > > > > > > > > > doing something wrong? > > > > > > > > > > > > > > > > > > > > > > > > =3D=3D=3D=3D BEGIN LOG =3D=3D=3D=3D > > > > > > > > > > > > hbsd-current-01[shawn]:/home/shawn/tmp $ ./xattrtes= t xattrtest > > > > > > > > > > > > xattrtest: Named attributes not enabled: No error: 0 > > > > > > > > > > > > hbsd-current-01[shawn]:/home/shawn/tmp (1) $ zfs li= st /usr/home/shawn > > > > > > > > > > > > NAME USED AVAIL REFER MOUNTPOINT > > > > > > > > > > > > rpool/usr/home 10.4G 71.4G 9.85G /usr/home > > > > > > > > > > > > hbsd-current-01[shawn]:/home/shawn/tmp $ zfs get xa= ttr rpool/usr/home > > > > > > > > > > > > NAME PROPERTY VALUE SOURCE > > > > > > > > > > > > rpool/usr/home xattr on default > > > > > > > > > > > > =3D=3D=3D=3D END LOG =3D=3D=3D=3D > > > > > > > > > > > > > > > > > > > > > > > > That xattrtest application is yours from: > > > > > > > > > > > > https://people.freebsd.org/~rmacklem/xattrtest.c > > > > > > > > > > > No idea. It works for me. You used up-to-date kernel = sources? > > > > > > > > > > > (Check that VIRF_NAMEDATTR is defined in sys/sys/vnod= e.h.) > > > > > > > > > > > Oh, and one more thing to check. zfs_xattr_compat nee= ds to be non-zero. > > > > > > > > > > > (It's found in sys/contrib/openzfs/module/os/freebsd/= zfs/zfs_vnops_os.c. > > > > > > > > > > > It's initialized to 1 and I don't see anything that s= ets it to 0?) > > > > > > > > > > > > > > > > > > > > It is indeed set to 1. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The only thing I can think if is, if you changed xatt= r to on, you need to > > > > > > > > > > > reboot (or at least remount) to get it to take effect. > > > > > > > > > > > (Maybe try setting it to "dir" and then reboot/remoun= t. Maybe there is > > > > > > > > > > > a difference between "on" and "dir"?) > > > > > > > > > > > > > > > > > > > > Yeah, tried rebooting and still no go. Note that xattr = defaults to > > > > > > > > > > "on" in FreeBSD by default. My src tree is synced up to= FreeBSD commit > > > > > > > > > > 7e70d94acd68b3ac6b45f49d4ab7a0f7867c3ea7. I brought in = the ZFS patch > > > > > > > > > > you linked to. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Or, did you build zfs.ko some other way than as part = of a kernel build? > > > > > > > > > > > (It needs the patched .h files in the kernel sources,= not something in > > > > > > > > > > > /usr/include/sys > > > > > > > > > > > that has not yet been updated.) > > > > > > > > > > > All the ZFS changes are #ifdef'd, since OpenZFS requi= res the sources > > > > > > > > > > > build for older kernels. (Basically #ifdef'd on that = VIRF_NAMEDATTR mentioned > > > > > > > > > > > above.) > > > > > > > > > > > > > > > > > > > > Perhaps I need to do a clean build. I'll try that and r= eport back. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > It does remind me that I need to try a build of zfs.k= o by doing a "make" in > > > > > > > > > > > the module directory. > > > > > > > > > > > > > > > > > > > > > > You can try the attached trivial patch and see if it = spits out "pathconf ret=3D1" > > > > > > > > > > > on the console. > > > > > > > > > > > > > > > > > > > > I'll try that after a clean rebuild of the kernel. > > > > > > > > > > > > > > > > > > Clean rebuild didn't resolve it. However, I made some pro= gress. > > > > > > > > > > > > > > > > > > I created a dataset specifically for this since I can't r= eally unmount > > > > > > > > > my /usr/home dataset, so my example down below is a bit d= ifferent than > > > > > > > > > the previous example I gave. > > > > > > > > > > > > > > > > > > The xattr property is set to "on" for the dataset. Howeve= r, it's not > > > > > > > > > mounted with the xattr property. In order to get it to wo= rk, I had to > > > > > > > > > run the following commands: > > > > > > > > > > > > > > > > > > =3D=3D=3D=3D BEGIN LOG =3D=3D=3D=3D > > > > > > > > > $ sudo zfs umount rpool/scratch/xattr > > > > > > > > > $ sudo mount -t zfs -o xattr rpool/scratch/xattr /scratch= /xattr > > > > > > > > > $ zfs get xattr rpool/scratch/xattr > > > > > > > > > NAME PROPERTY VALUE SOURCE > > > > > > > > > rpool/scratch/xattr xattr on local > > > > > > > > > $ mount | grep xattr > > > > > > > > > rpool/scratch/xattr on /scratch/xattr (zfs, local, noatim= e, nfsv4acls, named attributes) > > > > > > > > > $ mount | grep named > > > > > > > > > rpool/scratch/xattr on /scratch/xattr (zfs, local, noatim= e, nfsv4acls, named attributes) > > > > > > > > > =3D=3D=3D=3D END LOG =3D=3D=3D=3D > > > > > > > > > > > > > > > > > > So it looks like FreeBSD does not honor the xattr zfs pro= perty, > > > > > > > > > otherwise you would see a whole bunch of datasets mounted= with the > > > > > > > > > "named attributes" flag in that last `mount | grep` comma= nd. > > > > > > > > I've looked at this a little more... > > > > > > > > There is a function xattr_changed_cb() that updates the xat= tr property > > > > > > > > information. > > > > > > > > It gets called when "zfs set xattr=3DXX " is d= one or when > > > > > > > > the mount option "xattr" is set. > > > > > > > > > > > > > > > > The question seems to be "Why was the stuff not correctly s= et for your file > > > > > > > > systems, although they show xattr=3Don?" > > > > > > > > > > > > This is indeed what I was inferring. xattr has been set to "on"= since > > > > > > the pool's creation as far as I can tell. Until experimenting w= ith > > > > > > your patch, I didn't really even know the xattr property even e= xisted. > > > > > I was able to reproduce this with a fresh zpool. > > > > > Although it reported "xattr on", that is not really accurate. > > > > > > > > > > I stuck a printf() in here (line#853-861 of > > > > > sys/contrib/openzfs/module/os/freebsd/zfs/zfs_vfsops.) > > > > > > > > > > /* should either have both of these objects or none */ > > > > > error =3D zap_lookup(os, MASTER_NODE_OBJ, ZFS_SA_ATTRS, 8, 1, > > > > > &sa_obj); > > > > > if (error !=3D 0) > > > > > return (error); > > > > > > > > > > error =3D zfs_get_zplprop(os, ZFS_PROP_XATTR, &val); > > > > > --> The printf here shows that error =3D=3D ENOENT. > > > > > if (error =3D=3D 0 && val =3D=3D ZFS_XATTR_SA) > > > > > zfsvfs->z_xattr_sa =3D B_TRUE; > > > > > > > > > > The printf() of error showed ENOENT. So, "xattr" actually does not > > > > > exist. "zfs get xattr " calls it "on" but that's not= accurate. > > > > > > > > > > As root, I did: > > > > > # zfs set xattr=3Ddir > > > > > - reboot > > > > > > > > > > This makes it work, although the above call still returns ENOENT. > > > > > It looks to me like zfsvfs_init() gets called from zfsvfs_create() > > > > > right at the beginning of zfs_domount(). > > > > > Later in zfs_domount() it calls zfsvfs_setup()->zfs_register_call= backs(), > > > > > which now finds the property (because of the "zfs set xattr=3Ddir= ") > > > > > and registers it via dsl_prop_register(). > > > > > > > > > > I don't know if the above is correct? > > > > > Personally, I would prefer to see "zfs get xattr " r= eply "not set" > > > > > instead of "on". > > > > > > > > > > rick > > > > > > > > > > > > > > > Setting the property makes it work, but only after rebooting > > > > > (a umount/mount would probably have the same effect, I think?). > > > > > > > > So I wonder why neither an unmount/mount nor a reboot causes `mount= | > > > > grep "named attribute"` to fail for me. HardenedBSD doesn't have any > > > > changes to ZFS that would cause that kind of behavior. I have to > > > > unmount, but manually mount with `mount -t zfs -o xattr ...` in ord= er > > > > to access the new feature you wrote. Weird. > > > So, you have done > > > # zfs set xattr=3Ddir > > > followed by a reboot and it still doesn't work? > > > > Correct, even a reboot does not work. > No idea. If you apply the atteched little patch (just printf's) and post > what gets printed out (when a mount that doesn't work is done), > it might help explain it. Turns out this was a big case of PEBCAK. I had misunderstood which value the xattr property should have been set to. After setting it to "dir" and rebooting, the ZFS datasets are now mounted with named attributes support. Thanks for your patience and I apologize for the noise. Now it's time to figure out how best to prevent fdlopen(extattrfd). :-) --=20 Shawn Webb Cofounder / Security Engineer HardenedBSD Signal Username: shawn_webb.74 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 --ggmycmozaswce6z3 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEA6TL67gupaZ9nzhT/y5nonf44foFAmf2o6cACgkQ/y5nonf4 4foHJBAAh3/EpGGRE5f4ifKHlkIk39XAC7LWEHZCKwis1mzcZnRm9IyhqXTjfGMA 8W4wxSvuLhSjPzveekyfN8Kbj+5Ac0fEBIANAJBPC6CDvgb8R8OxCXmWcd3OM0mb r4D/zHqMKvxSJcxjFEjNJ8blmib286XnoSbUxJH2HnK2S+VGp0w+YBmZoKX55gtV gfhPYcjEyzXzWLUyI5DR3NT10vJA3p/QyvybBagUnV7Zkv3Sis+Tofjd6ke5fMgY CmKfDH9OqFmKVtjHy7EKCFST5/PfP10iaSwNpz77n0JmISWOjk9cViRWivwyFfDC 4X+SUDu6ZVcyKGFfv1dwV8b1+OBev3CA+uvmcvEfPFfeJeYM9F1lKIcj3qsgCrjn yNg/jBEFezDJAtryQPqjcsH4+6P01WyfqgttAK+AREvkjU1IIe+Z3pgcQGvDx0cG P47uwfpST92cCbjppNzCNUzryNIxUzd+HeDGF6WQwObI0gsaEiT/IN2OFQqfWi8B mQUtFTGywNWOiKKgS4avxkUPaclLgqMpl79q8UX7TpZoRkmb882m4fUIf4dh/72V vhvl7QaXEoW6xV+NuPYf2YnAzriwOnY+LXHr+Rgcff/edy59Iv11j11EtLzQ4JRS HEKf5mmoEcvdv1NGyCU04WXGwFzkJ8zaMLL1fmmoIPu+yy8DzwM= =QulT -----END PGP SIGNATURE----- --ggmycmozaswce6z3--