From nobody Fri Mar 28 14:12:23 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 4ZPMtJ4LM5z5rvCT; Fri, 28 Mar 2025 14:12:40 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com [IPv6:2a00:1450:4864:20::535]) (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 4ZPMtH56xzz3mPK; Fri, 28 Mar 2025 14:12:39 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=TvFQSaCa; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of rick.macklem@gmail.com designates 2a00:1450:4864:20::535 as permitted sender) smtp.mailfrom=rick.macklem@gmail.com Received: by mail-ed1-x535.google.com with SMTP id 4fb4d7f45d1cf-5e61da95244so4076490a12.2; Fri, 28 Mar 2025 07:12:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1743171156; x=1743775956; 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=PdEedoBh+nEFBoUNt2d6Q6DrXZyS9UP7Jb1X+jbFOcA=; b=TvFQSaCaIUttE8h9qWhvKCWmMm1iKlErjcahJB5cCuYXz9EWSfbUSW9WtHI34jQiZO /jr06J8r8CFan8bx76ytQdBmw4crkftteLsY2Gd9aPug6MiYhhH08zUl5jlD7ozT5pYo GMqhgQbfRzgTTPBdkEkqYaJrtoamvQAWeLEdS9x8PQk3hTGxLSI1fievVUtFxRtrjAdt EWrwT8WgFyNs1pFrg89clM5HWkNV4/g90ajFWGt/vepm9pGBI8yn4ejznWjxFF87aGxs WnjgVBefaRSdNOFTgZPbo9dTcRbeFIu1R2ZN7n3iDb9gzLtl4icGmIyjrd5yw2WudYyJ voZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1743171156; x=1743775956; 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=PdEedoBh+nEFBoUNt2d6Q6DrXZyS9UP7Jb1X+jbFOcA=; b=n4PnxmwSX2LVPmeg7eWJ7gJ+ssR5hPCHTUrr+SyjndbgRIhy265skDtZr2tsGkZ0zV 6ygFb2L/d4jBv9OvVaonM1VsMrC+UcK3z+ZgANFZDDC5AaIAKDuAhMIF90612xvl79VX rfDbwBZOhgbmxkb7jUH6KHpggQln/69Bwfj116aH8bo6eh3gKr+2wV5g8lCPbmrzJ9fQ YK2uf5cahsgko9tprfcCDAPRIFwP9we+d7wxm3JutKaSYIBxWD9H6dCrGArvAbCcCbKJ aGEuhyU+pGjv1GUQzObP0CSmHFiugJak2AkdBBsBfCQhEp+hGrvoEy14+anykTh+uWjZ d/Uw== X-Forwarded-Encrypted: i=1; AJvYcCWenlBVK0WtKTkVuVBfvvJLgib47f2RODsFOPCQ/RC8OYb4VvanPvDKgb+HZCyb2SwatOeVPbotNYnOo90=@freebsd.org, AJvYcCX4HYAkjHO//4mAzgnfVvXzoHdeeR1nOdez6qneUuHBjLxzwpLxiMDyG3Yk3wE6Kk8aT5jcWQSrZQaScmdlzgdt@freebsd.org, AJvYcCXGsLk7MHpZ3uCS48/QQfzFkQkL7cs4Bgt3KKbhBDWfubp1z/ATdDhDDmpQkSonLkSYU6w3@freebsd.org X-Gm-Message-State: AOJu0Yz/yFh9RseAdl62Pgx6XIIL5p1VSIcqF7EERRL5IKr3K26ad6ER JXUvnkh3ZEbp+wjCj1uTfvx/S0Bd+/ZmQHC7Al81Il5Erw75CmvmKM21EX9ju63w+TsDZKj8fB4 ZuoElk8iYBui/EZ+PH0F9oHIGyg== X-Gm-Gg: ASbGncuyvPeJgcmyzydj3CrP/EGlsKq4n7v0feCvv+nUqfFxi7ZMe8A7mwvA1P7Uaa3 U1f6X/gOxGi0/+t4F1uYXzqGBlWmh99U9GT/dtNOEb/U+24hTiyB/kIxPcLvNIExBjNLEcfmuxd 37TlNXRY0XxtvskBaEY41fQIKnW3TEueoiSyg/YJUFxuG/+g3Z/PHMyamSYWfhNZOJ9yHj X-Google-Smtp-Source: AGHT+IGrNW3LnHYx7g56LfYK/SSp281W6IRH5ByiUpH7z7+LV0FnbbLGdof0M6s6/8/3jLml64I3aurbHSkG16Fqfpw= X-Received: by 2002:a05:6402:524e:b0:5ed:1262:c607 with SMTP id 4fb4d7f45d1cf-5ed8f907b65mr6745385a12.31.1743171155579; Fri, 28 Mar 2025 07:12:35 -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: Fri, 28 Mar 2025 07:12:23 -0700 X-Gm-Features: AQ5f1JoHvP3As0nAGKj8KNJG3b3DIYhItbcP0Fitw46EfAtSojTBCwlHrP9VF_U 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.49 / 15.00]; SUSPICIOUS_RECIPS(1.50)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-0.997]; NEURAL_HAM_SHORT(-0.99)[-0.993]; 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::535: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)[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]; FREEMAIL_ENVFROM(0.00)[gmail.com] X-Rspamd-Queue-Id: 4ZPMtH56xzz3mPK X-Spamd-Bar: -- On Thu, Mar 27, 2025 at 11:52=E2=80=AFAM Lionel Cons wrote: > > On Thu, 27 Mar 2025 at 19:31, Lionel Cons wrot= e: > > > > On Tue, 25 Mar 2025 at 20:06, Lionel Cons wr= ote: > > > > > > 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 > > > > YFI Roland Mainz pointed out that > > https://datatracker.ietf.org/doc/html/rfc5661#section-5.3 page 106 > > describes an attribute directory limits. I have lived with this RFC for quite a few years. Yes, in the section he has quoted it states that subdirectories cannot be created. Then elsewhere (I'm not going to search for it now) it talks about handling of subdirectories of the named attribute directory. (I suppose "not being able to create them" is not the same as "handling them, if they already exist".) I have gone with "no subdirectories allowed" in the patch, as suggested by Lionel. > > > > Lionel > > Is there a freebsd mailinglist with minimum other traffic where this > kind of debate&planning can be done? There is no mailing list specific to NFS for FreeBSD. Also, "low noise" implies people that need to see the discussion do not see it. (I don't find freebsd-current@ too noisy and freebsd-arch@ is read by few. I included it here, since it is technically the correct place for "new feature" discussions.) rick > > Lionel