From nobody Wed Mar 26 14:47:26 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 4ZN8ld5z1Hz5s2rM; Wed, 26 Mar 2025 14:47:41 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com [IPv6:2a00:1450:4864:20::531]) (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 4ZN8lc3DCVz46D7; Wed, 26 Mar 2025 14:47:40 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=G4m27Als; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of rick.macklem@gmail.com designates 2a00:1450:4864:20::531 as permitted sender) smtp.mailfrom=rick.macklem@gmail.com Received: by mail-ed1-x531.google.com with SMTP id 4fb4d7f45d1cf-5e686d39ba2so13242762a12.2; Wed, 26 Mar 2025 07:47:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1743000459; x=1743605259; 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=fio+mg6NqN92MNqEGQkUZJ7LX78RyYbJRV2DyfiK/G8=; b=G4m27Alsg2A5nuLsqe6WgDXVG456LfTohxHMvHOiTeRzQ6D8oCzAmYuFETAb1pvphM OaQ/zsW0qTdM2FJLrEiofCgK+v7tdA+lgCteAzY0cZ2IQG7pfo+XAfYiUqtM6K2KzG7g SCkTGaaUTN/a4GyiLWFnYEOBLDa3MxLEb4OaGqHsn4Npcl8M6y0oVDoYPMdpA45r4611 rulrCM9+bGg4mOLp0VjhxUOQali3qv+ovva/C1yMnfACGqzq0te8gWaWLIa7rEvfV/xJ 0fy6e/rMpjd1HvqQk/GhpPpDd7J+c6Ww51QmBAV+7nL/OMCYqomCEGUHAJmf5TJt/7dG tZAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1743000459; x=1743605259; 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=fio+mg6NqN92MNqEGQkUZJ7LX78RyYbJRV2DyfiK/G8=; b=rflGGiAEbBbGcmOygcoahfab1ewoXjnz4q/ce3h0ej9DU8VkJzP01u/0iayAO/+Imo ZgSoz7nDKEpzv0ADR2VR3IlqMnkjJXktN3eSS2r0szl1RB4FvvxKDFHlyHI99LFCFBOc oSFXV0H8sNPvOCuwbGQCQv42UzZUvlrDmcAd6y9kFcfA0YC9YuVtu0vOv/CbrwtplMwd 1z4UdqoHUVTQbjc+Ylq8WYAPnKJNrAm2oab1POQXJLPYMIrWcBRrQuAS9scuSLJ+0Kxa hQD8MdtMwcWbiqZckCn2dyQ28ZWxEdZQwf3QyG+tYvfh2o9avwUP/OEAGldw/y9bcpb1 /+OQ== X-Forwarded-Encrypted: i=1; AJvYcCX/gzf6fi79apufDiNAeBgkNL+bAHEvj6+BgeaZc8HyU6U1wE5mrx0VLJJ1yD2h4tkNvNyjXIt8BHD2SO8vm3JJ@freebsd.org, AJvYcCXC6yV2DgxMKNEa8JgnnsslzqENXh9UENwL+Kzi6Plm20K2BAs6Sqz8+ATQKekq+gM3/YmX@freebsd.org, AJvYcCXG72JCo/X896QAxwssBmUszqFVWHMSnKHucnlrsOBl+bwIySav2n6hh+XijhPus3rIwQKQ+9RwKA0T6Ys=@freebsd.org X-Gm-Message-State: AOJu0YxX1XFh3+ZtUpBOjFEpiG+K7f/4xaOeWq1kS9PhqKosLqJgks/L mgQL5FV0eXY9GqRES5knxOtKn+4EXTboAcLydDHZqjSo/3v2bwfkuyrBLYFY80f3eJ4O8jnSDXY LDxnFyQ4yF/vjXXbLDUN5XsVrKQ== X-Gm-Gg: ASbGncusHEEcUOtOS3y5Dajo0FV8LWQLtIIWCw0Bmk+epuvfqLQeRgXmQdyhSektEO0 WED2nA4Yh7rZwauS2CeDLmfxSnXlTBCp+II1WH8CXfUieS25i1zwaIlrMDE0/WKVrdfo4xu0sMm 75HfrGraWwog/7PgM3ECMF7znpE5M27E+fNBZtXw6iNYguRMbJOxwvfVmSIw== X-Google-Smtp-Source: AGHT+IGQf2mDgmC7M/LFFBLFEk/BhqW9bipN50Qe9mPpMT/sFt1PEry8BUJywN06oAhJXKO+aYTzLoFQMtTEvCM5mjg= X-Received: by 2002:a05:6402:35c4:b0:5e7:8efa:ba13 with SMTP id 4fb4d7f45d1cf-5ebcd40a6b3mr20238414a12.7.1743000458576; Wed, 26 Mar 2025 07:47:38 -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 07:47:26 -0700 X-Gm-Features: AQ5f1JqJ8TQw-qcA_cucbyltfl7hTh1s6YjNXlOJzli1jwVQhDuB0TdDMMbqysc Message-ID: Subject: Re: RFC: Solaris style extended attributes for FreeBSD To: Lionel Cons Cc: Andrew Walker , Konstantin Belousov , freebsd-arch@freebsd.org, FreeBSD CURRENT , Cedric Blancher Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spamd-Result: default: False [-2.46 / 15.00]; SUSPICIOUS_RECIPS(1.50)[]; NEURAL_HAM_LONG(-0.99)[-0.993]; NEURAL_HAM_SHORT(-0.99)[-0.993]; NEURAL_HAM_MEDIUM(-0.98)[-0.978]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; 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)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; TAGGED_FROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; FREEMAIL_FROM(0.00)[gmail.com]; FROM_HAS_DN(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::531:from]; MID_RHS_MATCH_FROMTLD(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_CC(0.00)[ixsystems.com,freebsd.org,gmail.com]; 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]; RCPT_COUNT_FIVE(0.00)[6] X-Rspamd-Queue-Id: 4ZN8lc3DCVz46D7 X-Spamd-Bar: -- On Tue, Mar 25, 2025 at 2:14=E2=80=AFPM Rick Macklem wrote: > > 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 w= rote: > > > > > > > > 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 prett= y > > > > > > straightforward. I am not suggesting that they should replace t= he > > > > > > current FreeBSD extended attributes > > > > > > > > > > The ZFS story is more complicated. When ZFS is configured with > > > > > `xattr=3Dsa`, xattrs are preferentially written into system attri= butes > > > > > (SA). This was introduced IIRC primarily for performance reasons > > > > > This allows tiny xattrs (~100 bytes) to be stored with the dnode = 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 older-= style > > > > > file-backed approach. > > > > > > > > > > What this means is that if someone is using this relatively commo= n > > > > > configuration (the default in TrueNAS and in many Linux distros),= then > > > > > the result would be that only some xattrs written via extattr wou= ld be > > > > > visible by directly opening the ZFS attr dir. It would also intro= duce > > > > > 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 extatt= r or > > > > > via the attr dir. I don't know off-hand whether this could lead t= o > > > > > corruption / unexpected behavior in ZFS but if you haven't looked= into > > > > > it yet you may want to make sure you're properly handling the cas= e > > > > > where someone has already written SA-backed xattrs. > > > > I am in the process of defining a new setting for the xattr propert= y > > > > I've called "named" which would need to be set for the Solaris styl= e > > > > extended attributes to work. > > > > > > > > I am making progress on the patch and am currently working through > > > > 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 ownershi= p > > > > (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 and > > > > permissions for everyone. (It ignores the "mode" argument to > > > > the open.) > > > > --> As such, anyone who has access to the file object can access > > > > 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 mode bi= ts > > > > as specified by the "mode" argument to the openat() that create= d > > > > 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 supportable > > > > by both OpenZFS and NFSv4. > > > > > > No, please no subdirs for now. As far as I can see all consumes of > > > such an API (Windows, MacOS etc) use flat layouts for the attribute > > > 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 style > > 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 style > > of extended attributes they want on a "per file system basis" and that = FreeBSD > > style will be the default, since to change that would be a POLA violati= on, imho. > > (If others feel that having the two styles co-exist on the same file > > 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 support f= or 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 like "c= hmod(1)" > > need to be "named attribute aware"? (The fchmod(2) syscall works, = but > > does the command line need to know how to do it? If yes, this is w= ork. > > 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 wha= t > > their position will be? (Most of the changes are in the os/freebsd= /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 obviou= sly > do some testing, but my resources are limited. > > For example, the pynfs test suite does have some xattr testing in it. > However, I haven't used the pynfs test suite in a long time and am not > a Python guy. It would be nice if someone else fired it up and did this > testing. (If problems are found, I could probably track them down and > fix them.) Oops, it sounds like pynfs tests the Linux/FreeBSD style extended attribute= s and not these (called named attributes in the NFSv4 RFCs). --> There is supposed to be support in Solaris, if anyone happens to have a Solaris installation handy. rick > > rick > ps: In case you do not know, I am one guy who does this NFS stuff as > a spare time hobby. I am not paid any $$$ by anyone to do it. > > > > > rick > > > > > > > > Lionel