From nobody Tue Mar 25 20:53:01 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 4ZMhvc6r01z5rmxj; Tue, 25 Mar 2025 20:53:00 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com [IPv6:2a00:1450:4864:20::52b]) (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 4ZMhvb3Fgfz3JBh; Tue, 25 Mar 2025 20:52:59 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=G6rRXcMI; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of rick.macklem@gmail.com designates 2a00:1450:4864:20::52b as permitted sender) smtp.mailfrom=rick.macklem@gmail.com Received: by mail-ed1-x52b.google.com with SMTP id 4fb4d7f45d1cf-5e5e22e6ed2so9415640a12.3; Tue, 25 Mar 2025 13:52:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1742935978; x=1743540778; 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=ykuMpv0z8ghbNWBUh9kmoCeAB4Tr1onR2bPNfc9gSZI=; b=G6rRXcMIFX9nkYbV3HVMJK9v9+OO29QTHL5thq2oYvXYq581fGPl+aCPBXlrDZPwCw mZXt4Z9ZRdjMVMAotOdXtQII9p3SKMCpRyOyMQRHIhPg0FcvrO/6gv2pOMev7r4ZQR8M iWk09iw7IPfCwvUIJs4rtteY7WnvHjzzlAxiN9UX02ia0keeHRgVqBVqSnXl1pwI5P1u G07onwuhEMUzJxZBtwDd7Dnl//IU+gCYgMsFsKXvmgWDEpUwDTtizXGugxTyyMn7Jm/D vbHtRqW52oulj/RjOnL9Kxs3m9POonwGwFkdpSxZdz/bUdZvfMOOr+yT1nWfW0Recmf+ 54Dw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1742935978; x=1743540778; 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=ykuMpv0z8ghbNWBUh9kmoCeAB4Tr1onR2bPNfc9gSZI=; b=U+aURFZ1+FkD5jLeTPIdIuhmiMl1wuWCL/qHxvNTiTHn8zL/xTfYkgRfG6RdexUwnj NTk1lFUQUiqF73TKZfcdWo3ynFUbBW5INMB5rAkI9hmntHFKARLzGmR/6xVWdUT0SxDs 8/g9HGfQOdoufQCjdpt4iX2wWtekGtSyB+QI/WFSdvwlw37XdB49NkD31dg7GLfLut4M y29CeXrDffHHc2MSqXRi1ILaEBwinWI2nqsTOogyMVW6CZm2WsjXm8wy1J4vnFYbE3Vi t6dedz6LeCWUKZQfnv5cC1UX+7eBYCKBMjm3BTySYvwKRJLaSnl3KGm9Ls13E83PWF/c xCGg== X-Forwarded-Encrypted: i=1; AJvYcCUJGoTCtpyDNJenvqv17LKSwanyuQj3xQOGekMLIgVP+Dx6sDTf5PtEG8B5dtyDoM4JE/WP@freebsd.org, AJvYcCWdgb3g6/4zEAblm/lWjb7r+aRtw8ge7AlmT+aLqrjabxTtQE7FL0s9MsJCrB1Pw4djaIBzjx0YNv7VcfA=@freebsd.org, AJvYcCWlpJ3YGNM+vFihS25MovP4Dizmu6wP46R/CIKPGS4s0PQdf0yP/bF2C51ilOKuVzRtcXSLk938We7Hjy1j/3W6@freebsd.org X-Gm-Message-State: AOJu0Yx9dOo5e2wTufbk2PDhhkSOJ6PIYGt4t53dwBOA/BJFxFPUUgVh 8Mx4T/8qmi2grp39btZwg0z2B1BnLqL6PH/U0U08d/hKcsiYQv1SUOaoUOaKn1p92nauoTalQFY P9GY/OdH0vczRHg98cInZ/t7rrIiD X-Gm-Gg: ASbGncuIGwlM3vEWATp9zDY+/8Cj8OOinqEaZ3KFMO7yZ54hSYdi+COE7i61kObb3jr ReNY3IsNEV451VgEGmJrXchInFzbYTeDF5gMs/osHFj4mpBdO/jlZexTrxIsYocMrhNN3MsH407 B1UA2UmRxBzSrDsaHr73DFbXokJvugrYkQaI59+NJoEkSvZjMBIDIUV7BBKlSXgff0/bIA X-Google-Smtp-Source: AGHT+IG0KMT3cvsEMN5ttJ4PMYu/95/6dRYibSbpOascD3IuUrkpzd66fELP+TpV8uXYj+Is2PXIA6XoyIgvp1kcoew= X-Received: by 2002:a05:6402:4404:b0:5e7:110a:c55 with SMTP id 4fb4d7f45d1cf-5ebcd45f766mr18762127a12.18.1742935977643; Tue, 25 Mar 2025 13:52:57 -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 13:53:01 -0700 X-Gm-Features: AQ5f1JqHIrkIitgpppVtmqtt1nht5HHIs20Yd5Ft2WjRk2ONjUQHpuSGdJRbsMI 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 [-1.17 / 15.00]; SUSPICIOUS_RECIPS(1.50)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.98)[-0.984]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_SPAM_LONG(0.31)[0.310]; 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)[]; TAGGED_FROM(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::52b:from]; FREEMAIL_TO(0.00)[gmail.com]; ARC_NA(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_TRACE(0.00)[0:+]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; TO_DN_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_FIVE(0.00)[6]; MID_RHS_MATCH_FROMTLD(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org,freebsd-current@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_CC(0.00)[ixsystems.com,freebsd.org,gmail.com]; TAGGED_RCPT(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; DKIM_TRACE(0.00)[gmail.com:+]; MISSING_XM_UA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com] X-Rspamd-Queue-Id: 4ZMhvb3Fgfz3JBh X-Spamd-Bar: - 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 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 attribute= s > > > (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-styl= e > > > 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), the= n > > > the result would be that only some xattrs written via extattr would b= e > > > visible by directly opening the ZFS attr dir. It would also introduce > > > 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 int= o > > > 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 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 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 Free= BSD 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 t= his. (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 "chmod= (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 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/freebsd/zfs source subtree, which may make it easier?) rick > > Lionel