From nobody Tue Mar 25 21:26:12 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 4ZMjf138Vkz5rpXn for ; Tue, 25 Mar 2025 21:26:17 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: from mail-io1-xd2e.google.com (mail-io1-xd2e.google.com [IPv6:2607:f8b0:4864:20::d2e]) (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 4ZMjdz5y5Rz3hRP for ; Tue, 25 Mar 2025 21:26:15 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=hardenedbsd.org header.s=google header.b=UjNkWr2R; dmarc=none; spf=pass (mx1.freebsd.org: domain of shawn.webb@hardenedbsd.org designates 2607:f8b0:4864:20::d2e as permitted sender) smtp.mailfrom=shawn.webb@hardenedbsd.org Received: by mail-io1-xd2e.google.com with SMTP id ca18e2360f4ac-85b58d26336so512748239f.2 for ; Tue, 25 Mar 2025 14:26:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardenedbsd.org; s=google; t=1742937974; x=1743542774; darn=freebsd.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=0hIP9aCLWX64lvAdYx7a4CEPEHgF3jnnVH7WIMnr3Q4=; b=UjNkWr2RUbl9tXjSxuB+2zrHCjaD8GTzQ/2HI18Th3I2OCQqcD/uyAOo9+ruG8LGgE CoQO1lkhUtaognPx+WuQrusgzLqo8ChzZJlQQw0upR0S87eUlzdDlC60+Mw02hwYcujl y+0yKyrSwjwXqXda0AEZSEFNTqVFk21p83osSLTpGBauzGHZEHBmBXDWhlc+J+nz3aL2 gVP2WDTWD0ZMuQVmukyJgYAdDBNU32/BQvTfvWTFfifN5N7l6YOFNEnvhoCV4R9A9UjC R/g2RRdvRPkJPfdGe1kCfIXyhmdH4wdQmv8klLVbgUvXpQvnDBcPhD4UvAjVIvDWukLk /ngw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1742937974; x=1743542774; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=0hIP9aCLWX64lvAdYx7a4CEPEHgF3jnnVH7WIMnr3Q4=; b=EIRh434Z2PzhpjRLkbq98kULcBcaMlhdsUrDeY5jQw+NQwKXtCXTCHQzccyCt1e18b /7JxrcKp8lo1jITYdC7AxNKDxsFyisDOJxgl4ktfhSsQC/yNviY8MS0Q+lpCrBM4R3Q2 mcG6cXDLEUQx+gLOx0LJ/NS6fG2n+RHwMWKShbza81vfkReKz6e/NI3DqP5Vyppl7zJE Z7kvC3qSGWus3dpPDsvXWItCPAEFSdP+gYyPV1KG3YgrZdPfG4cl/4kciU8Omya3vrOY +HkPcLflncIo8odXsJ+fucFcNkJ6syKwu2BkSlMgpBeUO8tNvRaKw8Eidt3fvrYiJG0z 86bA== X-Forwarded-Encrypted: i=1; AJvYcCVCihM/bav+AQl9IA0JpEC6mqIvbGVB5WpGGbJRvtSOFi/96Tk2zJdlC6AnhXph40XkkItkoi1GAL1Sm90TReM=@freebsd.org X-Gm-Message-State: AOJu0Ywvd5oKCGBRsG2C9fEtIVAmtT+Y0qDWJDl4s1dC1ffXuFcjOFdf lTXkzAfG8qybA1OsTub2NL3QuDrHxAiLv+0eOCJLR/1aY3UY6apjqrJHSHgT5v8= X-Gm-Gg: ASbGncu4gMVX+WrdENiA6rIjlr5R6M9uDwyXxMQIC3dCMf+oVuUTeWpjh4PbNNiojrD UETmTOZS0g80+mMBRenarGPObHDEtBfDdwAm319AXalEQPD8gPWBsc6KVPuLZ9WqR/Sz8sS8wKy sjVRdrtC3WCKY5Ef5ed3j1WlkMEdhDtIQxEaG1PBXrARYjOSRQ+MWSLFHQUkzEiO5pV+UNiWU+X yMZJG1yA+oldy/RwGzAmM0zWO8C0IWFzPuLhak24Q2XVegt3dk0iYld9IDIbsyqhiQEVDVjlB4H zBPR1VYTP6DrEH5Gbw3q0jj7FDo= X-Google-Smtp-Source: AGHT+IFxdFR8DQnffv5z7d7BdZWPHRNJtPI/Gn4ZfpaSzDw+WR3d0dDrC9kcMAqyVbHogejxojwgbg== X-Received: by 2002:a05:6602:3890:b0:85b:3885:1592 with SMTP id ca18e2360f4ac-85e2cc60643mr1882832039f.10.1742937974272; Tue, 25 Mar 2025 14:26:14 -0700 (PDT) Received: from mutt-hbsd ([2001:470:4001:1::95]) by smtp.gmail.com with ESMTPSA id 8926c6da1cb9f-4f2cbecd047sm2495168173.143.2025.03.25.14.26.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 25 Mar 2025 14:26:13 -0700 (PDT) Date: Tue, 25 Mar 2025 21:26:12 +0000 From: Shawn Webb To: Rick Macklem Cc: Lionel Cons , Andrew Walker , Konstantin Belousov , freebsd-arch@freebsd.org, FreeBSD CURRENT , Cedric Blancher Subject: Re: RFC: Solaris style extended attributes for FreeBSD Message-ID: X-Operating-System: FreeBSD mutt-hbsd 14.2-STABLE-HBSD FreeBSD 14.2-STABLE-HBSD HARDENEDBSD-14-STABLE amd64 X-PGP-Key: https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/blob/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc References: 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 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="tlncmezvkdrnvgah" Content-Disposition: inline In-Reply-To: X-Spamd-Result: default: False [-5.09 / 15.00]; SIGNED_PGP(-2.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.988]; MID_RHS_NOT_FQDN(0.50)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; R_DKIM_ALLOW(-0.20)[hardenedbsd.org:s=google]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; DMARC_NA(0.00)[hardenedbsd.org]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_CC(0.00)[gmail.com,ixsystems.com,freebsd.org]; DKIM_TRACE(0.00)[hardenedbsd.org:+]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_TO(0.00)[gmail.com]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; MISSING_XM_UA(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; RCPT_COUNT_SEVEN(0.00)[7]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; TO_DN_SOME(0.00)[]; TAGGED_RCPT(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::d2e:from] X-Rspamd-Queue-Id: 4ZMjdz5y5Rz3hRP X-Spamd-Bar: ----- --tlncmezvkdrnvgah Content-Type: text/plain; protected-headers=v1; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Subject: Re: RFC: Solaris style extended attributes for FreeBSD MIME-Version: 1.0 On Tue, Mar 25, 2025 at 01:53:01PM -0700, 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 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-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.) >=20 > Also, I doubt anyone will ever do support for UFS? (I am certainly not > volunteering.) >=20 > 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.) >=20 > > > > > > > > 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, but > 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?) Hey Rick, I don't really have anything of importance to relay. While on the subject of filesystem extended attribute support with ZFS, though, I noticed that the support is broken for processes that have entered Capabilities Mode (called cap_enter(2)). I filed a bug report almost a year ago with both FreeBSD and OpenZFS. It might be worth a look: 1. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D277908 2. https://github.com/openzfs/zfs/issues/16058 Thanks, --=20 Shawn Webb Cofounder / Security Engineer HardenedBSD Tor-ified Signal: +1 303-901-1600 / shawn_webb_opsec.50 https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A= 4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc --tlncmezvkdrnvgah Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEA6TL67gupaZ9nzhT/y5nonf44foFAmfjH2EACgkQ/y5nonf4 4frEqQ/+I/Y+0EOsXLvenmL/6ISISNBGQKyaweFlJ6XJgRfogDkq3mAzNGJ4CF65 Ply8COM8/pRlCvr0OMfUZQy8bye22ttv+UXslesDbI7y1044m7qQS/y21Q9vgtsg QRTn3cjjdpiTCSYJfH65tBV6rMSqoaSV2DAGeA4Hq0QK22cj8mpRuv9uiCSiQ3Nz IwlJuFDJh9wAuucfsOcjJ6o7KDSszBTOd5P6YKJBbxKi4+dlMFPfEes5pOPiKjpL nshSQSG6UQ9e4WfMIQZdzTzWcXslFJNDVUNMugz+4w+7EMGv4VfsiGjEjPEoB0OU drapQQ4u06YdXHAbCdxsoTfa1A0NNlne5BZcUiV6II7tdS2VDNIXw7A+pxU7rVc7 6vsK2SVrRffuy5iUcmpQzNLM2oeYbsEX0r9z6vpM1dPw1Hh1gDJ+cC7yYNOOu/7M eXh6plWsZu39yjyFOH8EaiETy20v5Bmql4JxTPDQPcW8Yfw6mGD+p09HM3tMwuU/ xY7mihZnGpkFrTlxO7Ko4jO7nxosHZlVikgmYfT+NzEnLSTiIvbiHPObcq43leZm VgEGULCdxboCAz+KFZXbiDkfdJdtlphIvATsDICVkApTb/wnl5TQcZWbPCABpmKx BJtaa3F/JsnL/1tY3ykPGJ4SspKS9WFsPadxZ+NOWzcVZIBSJZM= =g0// -----END PGP SIGNATURE----- --tlncmezvkdrnvgah--