Date: Tue, 25 Mar 2025 21:26:12 +0000 From: Shawn Webb <shawn.webb@hardenedbsd.org> To: Rick Macklem <rick.macklem@gmail.com> Cc: Lionel Cons <lionelcons1972@gmail.com>, Andrew Walker <awalker@ixsystems.com>, Konstantin Belousov <kib@freebsd.org>, freebsd-arch@freebsd.org, FreeBSD CURRENT <freebsd-current@freebsd.org>, Cedric Blancher <cedric.blancher@gmail.com> Subject: Re: RFC: Solaris style extended attributes for FreeBSD Message-ID: <bodbbmijbarozw7sa57ecmcqqkerahuk55cznwjmwmsbjedgqb@etlrxtaqxqst> In-Reply-To: <CAM5tNy4S8h1nWNhLe7vVUAowAoYYdJ44RHNdeYLj06toeawEnQ@mail.gmail.com> References: <CAM5tNy6wkfPRUpkyHB3h6=fhJHf-eFSWWNdeHV5VLA_xG7pGDA@mail.gmail.com> <Z81ghZUaLYyrxxhd@kib.kiev.ua> <CAB5c7xpDGV0gZhxf7GRxxgH=yAy1xks-%2Bcsw8q=BAm-eh%2BPKDQ@mail.gmail.com> <CAM5tNy7AGQT2PDG9iztk-zTs=wS%2BJqXKAMUhG2gzHfUDdtwQMQ@mail.gmail.com> <CAPJSo4UomdX-e6W6%2BEQUwFcXzr58NMRoQhgec-Nwhi05qy7zCg@mail.gmail.com> <CAM5tNy4S8h1nWNhLe7vVUAowAoYYdJ44RHNdeYLj06toeawEnQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--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 <lionelcons1972@gmai= l.com> wrote: > > > > On Sat, 22 Mar 2025 at 21:34, Rick Macklem <rick.macklem@gmail.com> wro= te: > > > > > > On Sun, Mar 9, 2025 at 5:38=E2=80=AFAM Andrew Walker <awalker@ixsyste= ms.com> 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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bodbbmijbarozw7sa57ecmcqqkerahuk55cznwjmwmsbjedgqb>