Linux: Cross-platform user namespace xattrs compat

[ghost]

ZFS on Linux originally implemented xattr namespaces in a way that is
incompatible with other operating systems. On illumos, xattrs do not
have namespaces. Every xattr name is visible. FreeBSD has two
universally defined namespaces: EXTATTR_NAMESPACE_USER and
EXTATTR_NAMESPACE_SYSTEM. The system namespace is used for protected
FreeBSD-specific attributes such as MAC labels and pnfs state. These
attributes have the namespace string "freebsd:system:" prefixed to the
name in the encoding scheme used by ZFS. The user namespace is used
for general purpose user attributes and obeys normal access control
mechanisms. These attributes have no namespace string prefixed, so
xattrs written on illumos are accessible in the user namespace on
FreeBSD, and xattrs written to the user namespace on FreeBSD are
accessible by the same name on illumos.

Linux has several xattr namespaces. For Linux, ZFS encodes the namespace
in the xattr name for every namespace, including the user namespace. As a
consequence, an xattr in the user namespace with the name "foo" is stored
by ZFS with the name "user.foo" and therefore appears on FreeBSD and
illumos to have the name "user.foo" rather than "foo". Conversely, none of the
xattrs written on FreeBSD or illumos are accessible on Linux unless the name
happens to be prefixed with one of the Linux xattr namespaces, in which
case the namespace is stripped from the name. This makes xattrs
entirely incompatible between Linux and other platforms.

We want to make the encoding of user namespace xattrs compatible across
platforms. A critical requirement of this compatibility is for xattrs
from existing pools from FreeBSD and illumos to be accessible by the
same names in the user namespace on Linux. It is also necessary that
existing pools with xattrs written by Linux retain access to those
xattrs by the same names on Linux. Making user namespace xattrs from
Linux accessible by the correct names on other platforms is important.
The handling of other namespaces is not required to be consistent.

Add a fallback mechanism for listing and getting xattrs to treat xattrs
as being in the user namespace if they do not match a known prefix.

When setting user namespace xattrs, do not prefix the namespace to the
name. If the xattr is already present with the namespace prefix,
remove it so only the non-prefixed version persists. This ensures
other platforms will be able to read the xattr with the correct name.

Explicitly ignore freebsd:system namespace xattrs.

TODO:

• If xattrs with the user namespace prefix are already present, they
  will not be automatically fixed. Any existing xattrs must be
  manually rewritten on Linux for the name to be correct on FreeBSD.
  This also means that files may have a mix of incompatible and
  compatible names. Other platforms could strip the Linux user
  namespace prefix from xattr names so they are presented correctly.

• The newly written xattrs will no longer be visible on previous
  versions of ZFS on Linux. This behavior needs to be made optional
  with a feature flag and possibly a per-dataset property.

• There is no attempt to handle xattr names that clash with a namespace
  prefix. If you write an xattr named "user.foo" to the user namespace
  on FreeBSD, the "user." prefix will be stripped on Linux. This was
  partially the case already, except now the stripped name will also
  replace the prefixed name when updating the xattr. Likewise, setting
  an xattr to the user namespace using a name with the prefix of
  another namespace may cause the xattr to be manipulated in the other
  namespace. This is potentially a security issue. Such names must be
  forbidden.

• New tests should be added when the functionality is complete.

• Documentation will be needed.

[ghost]

• Rebased

[rick-mesta]

I was going to make a quip about the abi files having your $HOME directory embedded on them, but then the next commit fixed that right up 😁 . This LGTM 👍🏼

[rick-mesta]

I saw this double negation pattern throughout -- I take it this is by design, but why ?

[ghost]

It's a short hand way of converting the bit field to a boolean value, !!(0b1010 & 0b1000) -> !!0b1000 -> !0b0 -> 0b1

[rick-mesta]

👍🏼

[amotin]

Some consider those as Linux'isms. Discouraged in FreeBSD code, recommending != 0 instead.

[ghost]

I'm working on a few last fixups and squashing the commits, then if nobody objects I'll be ready to merge this.