On Wed, Mar 26, 2025 at 5:36 PM Andrew Walker <awal...@ixsystems.com> wrote:
>
> On Wed, Mar 26, 2025 at 5:05 PM Rick Macklem <rick.mack...@gmail.com> wrote:
> > I am now less convinced that a new value for xattr is needed.
> > I need to do more testing, but with xattr set to dir and not sa
> > (shown as "on" for zfs get xattr), the attributes seem compatible
> > and it is just the KAPI which changes.
> >
> > rick
>
> Rick, is it OK to serve the same information as an xattr and as a
> named attribute over NFS?
Good question. I don't have the answer. It seems that it "will work",
so so long as the "system attrnamespace" attributes cannot be accessed/created
on the named attribute side, I don't se an obvious problem (see below).
> I'm thinking of how this will interplay with xattrs via RFC8276 since
> they all occupy the same namespace.
The only issue I am aware of related to RFC8276 is size of the attribute
data. Right now, you can create a pretty large (as in data size in bytes)
attribute using ZFS and the setextattr API, which will not be accessible
via the RFC8276 operations. (They are limited to a single RPC to get
the entire attribute's data and the RPC size is typically limited to just
over 1Mbyte.)
--> They can fail now. With named attribute support, a NFSv4 client
will be able to read all the data.
>
> Being able to fchmod named attributes may also present some unexpected
> permissions issues with
> users trying to access them via xattr interfaces.
Yes, access is something I am just starting to test. Sofar I see the owner of
the file (and therefore also the attribute) can access the file no matter what
the attribute file's mode is.
Access permissions is where I'll be spending time doing testing for the
next while.
Will it be identical to the FreeBSD extended attribute model?
- I suppose we can make it so, but it probably is not so at this time.
I think it could be coded such that the mode of the attribute file is
ignored and access to the directory via the mode/uid/gid/acl of
the associated object is all that is checked.
--> This would make access permissions the same as the FreeBSD
extended attribute model but might make it less Solaris compatible?
(As Alexander mentioned, it would be nice to know what Windows and
Mac OSX does w.r.t. this, too.)
rick
>
> Andrew
