From nobody Sat Mar 22 20:33:44 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 4ZKrdB2n6mz5rD4G; Sat, 22 Mar 2025 20:34:06 +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 4ZKrd9088dz3K5G; Sat, 22 Mar 2025 20:34:05 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=BJIIvZlN; 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-5e5deb6482cso8340008a12.1; Sat, 22 Mar 2025 13:34:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1742675643; x=1743280443; 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=TZuIY42TPL/mvaBW8PZbELWSvy2dkAFAVqPk1WXwuFM=; b=BJIIvZlNvwtzVKcP08J3ZvTEk4Ik3zPjIR9Gv9R7cW4Q2mWTBb/1HqmY9vwvkjz0Ab ya95AhqEum2U3esHR9WG2tlv7/9O2RNR2EMfh0ebv2ECJ23O9/dJVLudD0+jtl5BIeym 0zJ24lEhKjIh+XEEoKIuxa2uVXC/vm3cUmqImuZJfMMPcuogsWU45iYJ890hqghlgQvb vGQg/l2JIZloiC1q9eX/hQB5OQYYOSbj4gO6NnOTLGmHrKKpAX203tv+I92xS6Q3jkkP 8+HIgaJ4ww0KKQS6r3PCLFuUtOzvR6hkxv8LigAJsWa6BIfamv7zU+xNyCAN1IOkpPhn o0nQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1742675643; x=1743280443; 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=TZuIY42TPL/mvaBW8PZbELWSvy2dkAFAVqPk1WXwuFM=; b=TVU0A9pok6LbnUYOP2dG1G4PVELTZp5FlU70h0Jbsl7oIz+/7k7+S80WdAQ45kfhVg BjrUKqXjp3x8/muuF07LQlkR7TpegE5VdCedtxY79D2k177Pd8/Eh1FgInz6tfjWNguD lJt6UIaBHjnfzxlP7/uhvccxd6Rz3AlO4cfRuQzBRsyuNuRGlSwrSKw7EUXUyu7qPqX7 B7ApziAFFlvw5DAi5ZgfdBTmTSYAOWmDJPXZGNRNnwmaV2ALvlHTV5MoY4jWX1CaLOlJ 6XmD8yZSBnjLyzt4M40w8p2C7ZEjZ2du4WIXhOQMa8bSUEj2yTirbehXtRphjsW4Z4Ep N9mQ== X-Forwarded-Encrypted: i=1; AJvYcCVb77QGpZBVOJzHWHwV1oFI8K0GWpWbryn8xrsiGff4j63NROeB7k64BTguqz2qsXoBShdM8Kl5DitcWQX9bbJa@freebsd.org, AJvYcCXSnVWFFX0reX/vTT9ek4IzFkCbU2+SimKfHQs9Hzs7gn+gdvl/Sos+ZjLFvLepQMJR45Rq6vuXv10PxxE=@freebsd.org X-Gm-Message-State: AOJu0YyD6KkBSgu66PcqBwPVb36gEPtyuOUH9Vw9Ac4/4/aCaW//G9cw x+VhMzBP1Jj7vZLsxiWVlVEtGOGTqMqRQ+G/LjJZY402LGwy5BaETH6AeUef73dVW/PSLM3NWhH NqUoTTdyTuNekgl8G4kSwSqfkMJgvAAk= X-Gm-Gg: ASbGncvf+B4/4HkfidWffxLcq43qGM6Q35pvb9Vh7Y39V9TCXoZXg6TIDuELYi5HeK5 d+9QZR3zvJBjMFqVL6s9/6d+N7bsSEv0zcBOhj1h7+zyO+O8uADdSk7iIbs33DEa2uZGL9oyCJH 5HRZXxMExPYhYwHUqMrg//NEmnU6RPTwQ8LRfQ8z9UAo+fBvdMlFcu9YOiNBo= X-Google-Smtp-Source: AGHT+IF0ULjdM72i0tNc/HX5zqQr+Lc8OsPSqTQaA+IVfRQD+H149nsfsfM3OhzxQmtGwkpOxzVQJ0W2R5Jeqq0kxKU= X-Received: by 2002:a05:6402:2712:b0:5e5:9c04:777 with SMTP id 4fb4d7f45d1cf-5eb9972ae95mr11292737a12.6.1742675642872; Sat, 22 Mar 2025 13:34:02 -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: Sat, 22 Mar 2025 13:33:44 -0700 X-Gm-Features: AQ5f1JrrVWJMSc1kzZT8e6Dt1E44XEoVUmR5UFOuQ0gabRSFA7JNUurmbCCGrpY Message-ID: Subject: Re: RFC: Solaris style extended attributes for FreeBSD To: Andrew Walker Cc: Konstantin Belousov , freebsd-arch@freebsd.org, FreeBSD CURRENT , Cedric Blancher , Lionel Cons Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spamd-Result: default: False [1.11 / 15.00]; SUSPICIOUS_RECIPS(1.50)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_SPAM_MEDIUM(1.00)[0.997]; NEURAL_SPAM_LONG(0.61)[0.612]; 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]; ARC_NA(0.00)[]; RCVD_TLS_LAST(0.00)[]; TAGGED_FROM(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_FROM(0.00)[gmail.com]; TO_DN_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::531:from]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; FROM_HAS_DN(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; RCPT_COUNT_FIVE(0.00)[6]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; TAGGED_RCPT(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org,freebsd-current@freebsd.org]; FREEMAIL_CC(0.00)[freebsd.org,gmail.com]; RCVD_COUNT_ONE(0.00)[1]; MISSING_XM_UA(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; FREEMAIL_ENVFROM(0.00)[gmail.com] X-Rspamd-Queue-Id: 4ZKrd9088dz3K5G X-Spamd-Bar: + 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 attributes > (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 common > configuration (the default in TrueNAS and in many Linux distros), 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 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 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 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. - 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? 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. - Does restricting this support to ZFS file systems with the xattr property set to "named" sound reasonable? 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.