On Tue, Mar 25, 2025 at 1:53 PM Rick Macklem <rick.mack...@gmail.com> wrote:
>
> On Tue, Mar 25, 2025 at 12:06 PM Lionel Cons <lionelcons1...@gmail.com> wrote:
> >
> > On Sat, 22 Mar 2025 at 21:34, Rick Macklem <rick.mack...@gmail.com> wrote:
> > >
> > > On Sun, Mar 9, 2025 at 5:38 AM Andrew Walker <awal...@ixsystems.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=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?)
Oh, and another one...
Testing. I have yet to hear from anyone trying to test the code. I obviously
do some testing, but my resources are limited.
For example, the pynfs test suite does have some xattr testing in it.
However, I haven't used the pynfs test suite in a long time and am not
a Python guy. It would be nice if someone else fired it up and did this
testing. (If problems are found, I could probably track them down and
fix them.)
rick
ps: In case you do not know, I am one guy who does this NFS stuff as
a spare time hobby. I am not paid any $$$ by anyone to do it.
>
> rick
>
> >
> > Lionel
