From nobody Tue Mar 25 21:14:04 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 4ZMjND1f1Xz5rnvH; Tue, 25 Mar 2025 21:14:20 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com [IPv6:2a00:1450:4864:20::536]) (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 4ZMjNC2cvwz3Wgj; Tue, 25 Mar 2025 21:14:19 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b="SH/WegaN"; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of rick.macklem@gmail.com designates 2a00:1450:4864:20::536 as permitted sender) smtp.mailfrom=rick.macklem@gmail.com Received: by mail-ed1-x536.google.com with SMTP id 4fb4d7f45d1cf-5e6167d0536so1026236a12.1; Tue, 25 Mar 2025 14:14:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1742937257; x=1743542057; 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=hQgAZTr7fZSlCmKqP3zbQ7WaYXWiewKe5baw/AD0ALQ=; b=SH/WegaNsyocdi4yO3OyPKsXupXMxak4OqDoOsvDb/3iUFmcby3KVhqpALNQWiNDxi Fn9ovHhDL9bHC2HPCI/GM1VrbHx6P3TIMmaPtR10W90PYAtL8iyC8+71VgtfSaZu1jT/ 6BMS3PEpH4S1Bq7q6M+MabKpN2q/UyzEfae+0Mhy3WyShvMjWG/crzUwXprXTzoJgCk5 MC86BQ8mkDmKNpfl6Eh/1o8SXe9A7vBEYQKotYsgN4/VcGPhtA9acDboLmZocd9JUvgB Ni24LqQpwopJ0JU4gouQV+MYKy6lgMnTaA66AKzwBnKAk4rfJ3ripj48Qw4GRwhKni+Y 7m8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1742937257; x=1743542057; 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=hQgAZTr7fZSlCmKqP3zbQ7WaYXWiewKe5baw/AD0ALQ=; b=UqMUs4N7T9+8fWQwh66K9h7IqgKBnbODfuVMueEFmdNfVnCTieXdVM40dvuB2gN9CI QttUWdiOdHVyPjLdb4Kl/ZhnGwLUkG9TscQOfNSuP5tSAP4/miFRdwOZPfmTXfou/sun HrbZgeduNSh1wiwbUqvI7QZPhwJ+uZtupq9wYg1vUxEs28+APnqJq1H8VNOYoHpY9ZUy uA6quGl3WKbzl5tn51jSUb2ngESSuqdu3g4LSyKEUUgNhe+ue5f+Q0UZtjwsB/V3CypT 9h7xJEh1HYjZgT8YsNO1qzBW4IP8pEG/GMogxj1dp0UIPH5Tdhn0ErDY77KDqnMjYiQH nFqw== X-Forwarded-Encrypted: i=1; AJvYcCUTlTSGBhjPwa9LtIpkNBRWIdDSGS37jYPsZ3C9nG7VxzdyPSRyLlKmVokQntaRKxt8mPnw@freebsd.org, AJvYcCVvuIcqaL6t17y3y5BGR7cAKZqwAAgUzUGBTJprScXtIJGqoaebFOl16o+OV69jRDwP9CntpxD+mryKKLg=@freebsd.org, AJvYcCVw98iOKTQL8WjKraVz2L5ujKIxeygq+TO7MfdkRXCZP1zWj6GtWZj/plFTTqELGf+biDJAyDBUPkHhvRn8Yap1@freebsd.org X-Gm-Message-State: AOJu0YyY3/SDIIWAvJ179x8BvXTXFJ37BxWzVovOe2K8l1t1Ka1zP8bO boEao7FMWpQcl/F2leuEFfbAgJGDPdRmU9Vn2xsHnNf/OtkdexjqhWrYFhFHt/HgK27iPPSi/kH qgG8gP5l6hkbxR045qOLOWvhXsA== X-Gm-Gg: ASbGncv6ZPdKQEp6MssLzog2FryjHYe0i+kAOEfHz1owPNgVkkLjQygPmaA001OagiH ivUQtXYTiM/hGURqk+BzqL8h9o9/pNP/011PK1wEjkp7RvGyOTwfEa+xjFU73cTuq9tAiuRyRkM MYqhorq7MLXIUFlvAra+j0uX184AQ0jGxsfxNoe2JfHVFqlDZGpriPcQ+LnQ== X-Google-Smtp-Source: AGHT+IHdDSTc2g57nc5KywPtXkf0FmjraRcVR3bLAIHnzL7WzpjDkY+//SR1QBVBFqceSyknWoXqduq+rp1r/drTMqw= X-Received: by 2002:a05:6402:1d4e:b0:5e7:2871:c137 with SMTP id 4fb4d7f45d1cf-5ebcd436714mr14771443a12.14.1742937256527; Tue, 25 Mar 2025 14:14:16 -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: Tue, 25 Mar 2025 14:14:04 -0700 X-Gm-Features: AQ5f1JpuwqDgzaZWnHju2jxmwAkcWWMAMSIybZDJB-620XOfNm93ZDrF5_fgu5Y 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.50 / 15.00]; SUSPICIOUS_RECIPS(1.50)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; MIME_GOOD(-0.10)[text/plain]; TAGGED_FROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::536:from]; ARC_NA(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; FREEMAIL_TO(0.00)[gmail.com]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_TRACE(0.00)[0:+]; TO_DN_SOME(0.00)[]; FREEMAIL_CC(0.00)[ixsystems.com,freebsd.org,gmail.com]; MISSING_XM_UA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; MID_RHS_MATCH_FROMTLD(0.00)[]; TAGGED_RCPT(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org,freebsd-current@freebsd.org]; RCVD_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCPT_COUNT_FIVE(0.00)[6] X-Rspamd-Queue-Id: 4ZMjNC2cvwz3Wgj X-Spamd-Bar: -- 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 wro= te: > > > > > > 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 pretty > > > > > straightforward. I am not suggesting that they should replace the > > > > > current FreeBSD extended attributes > > > > > > > > The ZFS story is more complicated. When ZFS is configured with > > > > `xattr=3Dsa`, xattrs are preferentially written into system attribu= tes > > > > (SA). This was introduced IIRC primarily for performance reasons > > > > This allows tiny xattrs (~100 bytes) to be stored with the dnode an= d > > > > 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-st= yle > > > > file-backed approach. > > > > > > > > What this means is that if someone is using this relatively common > > > > configuration (the default in TrueNAS and in many Linux distros), t= hen > > > > the result would be that only some xattrs written via extattr would= be > > > > visible by directly opening the ZFS attr dir. It would also introdu= ce > > > > 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 extattr = or > > > > via the attr dir. I don't know off-hand whether this could lead to > > > > corruption / unexpected behavior in ZFS but if you haven't looked i= nto > > > > 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 property > > > 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 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 ownership > > > (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 th= at > > > 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 bits > > > as specified by the "mode" argument to the openat() that created > > > 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 Fr= eeBSD > style will be the default, since to change that would be a POLA violation= , 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 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 like "chm= od(1)" > need to be "named attribute aware"? (The fchmod(2) syscall works, bu= t > does the command line need to know how to do it? If yes, this is wor= k. > 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/freebsd/z= fs > 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 obviousl= y 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.) 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