Re: RFC: Solaris style extended attributes for FreeBSD

Shawn Webb <[email protected]> Tue, 25 Mar 2025 21:26:12 +0000
Newsgroups	gmane.os.freebsd.architechture,gmane.os.freebsd.current
Message-ID	<bodbbmijbarozw7sa57ecmcqqkerahuk55cznwjmwmsbjedgqb@etlrxtaqxqst>
On Tue, Mar 25, 2025 at 01:53:01PM -0700, Rick Macklem wrote:
> On Tue, Mar 25, 2025 at 12:06 PM Lionel Cons <[email protected]> wrote:
> >
> > On Sat, 22 Mar 2025 at 21:34, Rick Macklem <[email protected]> wrote:
> > >
> > > On Sun, Mar 9, 2025 at 5:38 AM Andrew Walker <[email protected]> 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=sa`, 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.
> >
> > 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 >= 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 FreeBSD
> 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 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 "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?)

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=277908
2. https://github.com/openzfs/zfs/issues/16058

Thanks,

-- 
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/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc
signature.asc (application/pgp-signature, 833 B)