On Sun, Mar 9, 2025 at 11:35 AM Andrew Walker <awal...@ixsystems.com> wrote: > > On Sun, Mar 9, 2025 at 8:24 AM Rick Macklem <rick.mack...@gmail.com> wrote: > > > > On Sun, Mar 9, 2025 at 5:46 AM Andrew Walker <awal...@ixsystems.com> wrote: > > > > > > Out of curiosity, how are you preventing users from creating / writing > > > xattrs with the `system?` name prefix. In ZFS on FreeBSD IIRC this > > > prefix is used to determine whether the corresponding attribute when > > > accessed via the extattr interface is in the user or system > > > namespaces. > > A couple of comments... > > 1 - My current thinking would be a ZFS fs would be configured for one > > or the other (mixing them is weird as noted by the next comment), > > There is currently the xattr property that can be set to "dir" or "sa". > > 2 - I haven't looked at system space FreeBSD attributes yet (I will), > > but when mixing them, you can get two attributes with the same name > > showing up in the named attribute directory (the open gets the named > > attribute one). I haven't yet figured out how to get rid of the > > duplicate. > > 3 - I assume the patch could include code that excludes "system.xxx" names > > from the directory. (I'll do some testing.) > > > > > I vaguely recall some people may have patched the FreeBSD > > > samba server for instance so that it writes security information > > > related into the system namespace when samba is configured as a domain > > > controller so some care needs to be taken with namespaces. > > > > > > You may also need to potentially restrict ones with `security.` and > > > `trusted.` prefixes in case the ZFS data is replicated to Linux > > > systems (because those are privileged namespaces and it may introduce > > > a CVE). > > Thank for the info. I didn't know what Linux does. > > > > rick > > Rick, one other thing to maybe consider is the size of attributes that > you allow to be written via this special open flag. You can > potentially write an attribute that when accessed via extattr will > cause malloc failure because it will basically go OOM. For example if > you create a 30 GiB attribute in the ZFS attr dir, then accessing via > extattr will require allocating a 30 GiB buffer. So you'd probably > want to limit to something like 2 GiB max per attribute (which is what > we do in TrueNAS). I assume you are referring to accessing the attribute via getextattr? One of the main reasons people want the Solaris kind (you seem to call them streams?) is avoiding the size limitations related to FreeBSD (or Linux) extended attributes. I do know that FreeBSD allows pretty large ones for ZFS, but the NFSv4 crowd is against accessing extended attributes (not via named attributes) larger than Kbytes.
I'm surprised you allow 2Gbytes for TrueNAS, since the limit for the NFSv4 extension is around 1Mbyte. (RFC8276 specifies the NFSv4.2 extension for Linux style extended attributes and the getextattr reply needs to be in a single RPC, which is normally limited to about 1Mbyte. There is talk of increasing this to 8Mbytes, but I don't know if Linux has gotten there yet.) rick
