From nobody Wed Mar 26 15:43:55 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 4ZNB0p6Thrz5s60K; Wed, 26 Mar 2025 15:44:10 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-ej1-x62a.google.com (mail-ej1-x62a.google.com [IPv6:2a00:1450:4864:20::62a]) (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 4ZNB0n2mGfz3Z80; Wed, 26 Mar 2025 15:44:09 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=jMDZWz6f; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of rick.macklem@gmail.com designates 2a00:1450:4864:20::62a as permitted sender) smtp.mailfrom=rick.macklem@gmail.com Received: by mail-ej1-x62a.google.com with SMTP id a640c23a62f3a-aaee2c5ee6eso1050679666b.1; Wed, 26 Mar 2025 08:44:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1743003846; x=1743608646; darn=freebsd.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=CjlYSRcS1k2+wU1YIDYyY4mND507im6IJG3Sx+eLytk=; b=jMDZWz6feWk1uQP/bVDanT6gOyoTtMo3uA44Z6fHe4NXRHPeKVOd3RY/AabpCV/pr6 n/H0KRQ0jxQtF/ab0MGapJS5aKTfiRSCVixuNrUIOrqZlR/8ZMZTLA7tkojX6l4Av7d/ eG0JmM+ylsZ/v5DFZHDh43GbTNvEqbY4NIAurYsX12H3IZRHuigQHz/JLF4Kt2kxzNui Cw7qQtwu53cLbqTvHrpSQj088vO4wXMoo/TSFxDEcV/PbuHyQe5k12oKj36U5YOk4Jja Q7090ZSRSNH5bGk7+gDZLaWYOQOddRpbIqhpZo9a0YOes6DaqNlzy+oBzBuLlHOfxCl3 xvsw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1743003846; x=1743608646; h=content-transfer-encoding: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=CjlYSRcS1k2+wU1YIDYyY4mND507im6IJG3Sx+eLytk=; b=SnpDNWFeC3AOOJQIFwbTn2NeSgRxfxmFqDTBpe1wqpdSv9Ap1LXocROIg6ft4ciQiU p1HnOwvea65FwR+DKHhwgHL4UULB7Gxp2DNKENBbezLK3T2O7wVRBewrAkJCkkuc/JwD UAufDUpdsmE8M88SB+42PXTDgqgXKWUyHzpoUdJEfPp3enQqivH95JDaKjb66kB+bHuz JeoelfcEd8xcWaQiFSijaeAJyoEOcaFKeghHvPo0vJikgZ3LdTLcjKs3TOeesnxAN+Ze 8zn7qt5des24HALsofZscKy49XO6yfg3+PJj3JBT6bOlIrNmu9I2MzGy5/nkhOG8DSwG mZUA== X-Forwarded-Encrypted: i=1; AJvYcCVot7JBwvmrH+aKFbp7sznbGSD3bluiNXt++B5IJXCXDVGSTbh+Sqj4tF7VmkkYiApNshP7@freebsd.org, AJvYcCWI9sv0B7R7ZWlCU6Ot3rc5NT3ksmx/GauwmGgepXzSE8cfRs5GjBGUJ6oPP2do3zSeuAf7orQEdlqBoM2VvggJ@freebsd.org, AJvYcCXOTxyrTRJXSNlZWIIRbeDMVWBHDFuYT0pFNCFLfi3c+ND0nRt1C/HOI+4V6uXPoYBBl3aV+tGjfqy+Vkc=@freebsd.org X-Gm-Message-State: AOJu0YzG+DvzGIHYNH7NzZkTJfenk6dzQCJO9kSGkAxkjUFInFoEIwMB Fp09h75t8tygEXbLREO5UlcAlQdn72w/DfeApPb22bV4ifpN/ElYORIgh5d6l9dLBIMgOIfLwHj oKocrrdDC+jas8PVA7SPvaIDiZA== X-Gm-Gg: ASbGncvaB9XwfhPRbySQgKkDyqyHsOaSGEmRBzp7UhfLOHo75xGuU7rhQrWsmbrwVjB kOmpp49HbHUy3Frs8yO0z5VV9Wi7A0o3lczquJnb5HE+oc5W3PBcBDSzwa3bV7N7tYR4z7vomdV 1Y/CwumFIdk8JTzzCt724HuRyUf0hdRsl8A4v3vAo5anbdmsC6s5pjKN8nGGlBfJ1Fui0E X-Google-Smtp-Source: AGHT+IEN/wp1Kq1NiXn8G6LCbpadDKkLZ+1jOwBcfom9ojmOimA7Cfjh/fTTtjkAGvCI7uWiiXcL01/wMAeiU2g4bGk= X-Received: by 2002:a17:906:6a0c:b0:ac3:8790:ce75 with SMTP id a640c23a62f3a-ac3f20b04c3mr2208645866b.10.1743003846087; Wed, 26 Mar 2025 08:44:06 -0700 (PDT) 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 References: In-Reply-To: From: Rick Macklem Date: Wed, 26 Mar 2025 08:43:55 -0700 X-Gm-Features: AQ5f1JoCVBVV3Vw4L6bTOxmWaKHOgij1kpm8oBu-LUYS0EJUq87fXt8OVQFihQM Message-ID: Subject: Re: RFC: Solaris style extended attributes for FreeBSD To: Cedric Blancher Cc: Lionel Cons , Andrew Walker , Konstantin Belousov , freebsd-arch@freebsd.org, FreeBSD CURRENT Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spamd-Result: default: False [-2.41 / 15.00]; SUSPICIOUS_RECIPS(1.50)[]; NEURAL_HAM_LONG(-0.99)[-0.995]; NEURAL_HAM_MEDIUM(-0.99)[-0.986]; NEURAL_HAM_SHORT(-0.93)[-0.933]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_TO(0.00)[gmail.com]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; TO_DN_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::62a:from]; TAGGED_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; FREEMAIL_FROM(0.00)[gmail.com]; FROM_HAS_DN(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_FIVE(0.00)[6]; MID_RHS_MATCH_FROMTLD(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_CC(0.00)[gmail.com,ixsystems.com,freebsd.org]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org,freebsd-current@freebsd.org]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; TAGGED_RCPT(0.00)[]; MISSING_XM_UA(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; FREEMAIL_ENVFROM(0.00)[gmail.com] X-Rspamd-Queue-Id: 4ZNB0n2mGfz3Z80 X-Spamd-Bar: -- On Wed, Mar 26, 2025 at 8:18=E2=80=AFAM Cedric Blancher wrote: > > On Wed, 26 Mar 2025 at 10:39, Lionel Cons wrot= e: > > > > On Tue, 25 Mar 2025 at 22:14, Rick Macklem wro= te: > > > > > > On Tue, Mar 25, 2025 at 1:53=E2=80=AFPM Rick Macklem wrote: > > > > > > > > On Tue, Mar 25, 2025 at 12:06=E2=80=AFPM Lionel Cons wrote: > > > > > > > > > > On Sat, 22 Mar 2025 at 21:34, Rick Macklem wrote: > > > > > > > > > > > > On Sun, Mar 9, 2025 at 5:38=E2=80=AFAM Andrew Walker wrote: > > > > > > > > > > > > > > > Since ZFS is already wired for them, adding the basics is p= retty > > > > > > > > straightforward. I am not suggesting that they should repla= ce the > > > > > > > > current FreeBSD extended attributes > > > > > > > > > > > > > > The ZFS story is more complicated. When ZFS is configured wit= h > > > > > > > `xattr=3Dsa`, xattrs are preferentially written into system a= ttributes > > > > > > > (SA). This was introduced IIRC primarily for performance reas= ons > > > > > > > This allows tiny xattrs (~100 bytes) to be stored with the dn= ode and > > > > > > > up to 64 KiB of xattrs to be stored in the dnode spill block.= If > > > > > > > additional space is needed then they are written using the ol= der-style > > > > > > > file-backed approach. > > > > > > > > > > > > > > What this means is that if someone is using this relatively c= ommon > > > > > > > configuration (the default in TrueNAS and in many Linux distr= os), then > > > > > > > the result would be that only some xattrs written via extattr= would be > > > > > > > visible by directly opening the ZFS attr dir. It would also i= ntroduce > > > > > > > a mechanism whereby an xattr with the same name is written to= two > > > > > > > different ZFS locations, which would potentially cause you to= see > > > > > > > different xattr data depending on whether you read it from ex= tattr or > > > > > > > via the attr dir. I don't know off-hand whether this could le= ad to > > > > > > > corruption / unexpected behavior in ZFS but if you haven't lo= oked into > > > > > > > it yet you may want to make sure you're properly handling the= case > > > > > > > where someone has already written SA-backed xattrs. > > > > > > I am in the process of defining a new setting for the xattr pro= perty > > > > > > I've called "named" which would need to be set for the Solaris = style > > > > > > extended attributes to work. > > > > > > > > > > > > I am making progress on the patch and am currently working thro= ugh > > > > > > permissions (or authorization if you prefer). > > > > > > > > > > > > Here is what OpenZFS appears to do currently. > > > > > > I am wondering if these sound reasonable for these attributes? > > > > > > > > > > > > - When an attr directory is created for a file object, the owne= rship > > > > > > (uid and gid) is set to the same value as the file object. > > > > > > The mode is set to 041777 (a directory with sticky bit set an= d > > > > > > permissions for everyone. (It ignores the "mode" argument to > > > > > > the open.) > > > > > > --> As such, anyone who has access to the file object can acc= ess > > > > > > the extended attribute directory. > > > > > > > > > > Yes, that is the expected behaviour > > > > > > > > > > > > > > > > > - When an attribute is created in the attribute directory, the = uid is > > > > > > set to that of the creating process (cr_uid), the gid is set= to that > > > > > > of the directory (which is also the gid of the file object). > > > > > > The mode is set to that of a regular file with low order mod= e bits > > > > > > as specified by the "mode" argument to the openat() that cr= eated > > > > > > it. > > > > > > The mode can be changed with fchmod(2). > > > > > > --> As such, access to each attribute file is controlled by the > > > > > > attribute file's creator. > > > > > > > > > > > > Any comments on the above? > > > > > > > > > > Yes, that would be the expected behaviour. > > > > > > > > > > > > > > > > > A couple of other questions... > > > > > > - Should subdirectories of the attribute directory be supported= ? > > > > > > I currently do not allow this, but it appears to be supportab= le > > > > > > by both OpenZFS and NFSv4. > > > > > > > > > > No, please no subdirs for now. As far as I can see all consumes o= f > > > > > such an API (Windows, MacOS etc) use flat layouts for the attribu= te > > > > > and alternate data streams virtual dirs > > > > > > > > > > > > > > > > > - Does restricting this support to ZFS file systems with the > > > > > > xattr property set to "named" sound reasonable? > > > > > > > > > > What does that mean? > > > > > Also, it should be "on" by default, both in FreeBSD ZFS, UFS and = NFS >=3D v4.1 > > > > Hmm. I think (and the discussion with Andrew seemed to confirm it) > > > > that they do not > > > > mix well with FreeBSD/Linux style extended attributes. (For example= , > > > > the code that > > > > checked access for the parent directory is disabled for FreeBSD sty= le > > > > attributes and > > > > this is intentional, according to the comment.) > > > > > > > > Also, I doubt anyone will ever do support for UFS? (I am certainly = not > > > > volunteering.) > > > > > > > > The above means that a sysadmin will need to choose between which s= tyle > > > > of extended attributes they want on a "per file system basis" and t= hat FreeBSD > > > > style will be the default, since to change that would be a POLA vio= lation, imho. > > > > (If others feel that having the two styles co-exist on the same fil= e > > > > system is needed, > > > > there might be a way to do it, but doing so properly won't be easy. > > > > Another example > > > > is naming. If both co-exist on the same file system, you can end up > > > > with two different > > > > attributes with the same name. I did this during testing, so I know= it > > > > can happen.) > > > > > > > > > > > > > > > > > > > > > Thanks for any comments, rick > > > > > > ps: I have not, as yet, heard any comments w.r.t. whether or > > > > > > not this should go into FreeBSD15. (No rush on this one, > > > > > > but comments would be appreciated. > > > > > > > > > > I'd prefer the integration as soon as possible. > > > > A couple of problems here. > > > > 1 - You and Cedric are the only ones that have spoken up with suppo= rt for this. > > > > (Having said that, no one has spoken up against it.) > > > > 2 - Someone needs to do the "userspace" lifting at some point. > > > > I haven't yet asked, so I do not know if you feel commands lik= e "chmod(1)" > > > > need to be "named attribute aware"? (The fchmod(2) syscall wor= ks, but > > > > does the command line need to know how to do it? If yes, this = is work. > > > > Probably more than I've spent getting the syscalls to work.) > > > > 3 - A lot of the changes need to go into OpenZFS and I have no idea= what > > > > their position will be? (Most of the changes are in the os/fre= ebsd/zfs > > > > source subtree, which may make it easier?) > > > Oh, and another one... > > > Testing. I have yet to hear from anyone trying to test the code. I ob= viously > > > do some testing, but my resources are limited. > > > > How can we do this? Grab patch, apply patch, build FreeBSD, install > > new FreeBSD kernel? > > > > The biggest issue for me is building and installing a new kernel in an > > existing FreeBSD installation, or finding someone in-house who can do > > that. > > Howto or short blog post would be nice > > @Rick: Can https://docs.freebsd.org/en/books/developers-handbook/kernelbu= ild/ > be used to built your patch? Not sure that still works? (At least, I think you need SRCTOP=3D/usr/src on the make command?) I'd just do "make buildkernel" when in the top level of the source tree. (You need the full source tree and not just kernel sources.) Then "make installkernel" will install it. --> If you want the kernel installed under a different name, you can.. # cd /usr/obj # cd down into GENERIC (can't remember all the subdirs in between) # make KERNEL=3D install Once you've done a "make buildkernel", you can do the same as above and use "make SRCTOP=3D/usr/src" to build a kernel again, but I'm not sure thats any easier than "make buildkernel" in /usr/src? rick > > Ced > -- > Cedric Blancher > [https://plus.google.com/u/0/+CedricBlancher/] > Institute Pasteur