How can I use the Trusted xattr namespace on FreeBSD 11.2?

Question

I'm trying to translate whiteout files from the AUFS format to the kernel-overlay FS format. This entails marking certain directories with the extended attribute trusted.overlay.opaque = y. Unfortunately, it seems that at least by default, FreeBSD only supports the user and system namespaces for extended attributes. Is there any way around this restriction? The manual for extattr implies that some file system I could mount might support other namespaces, perhaps including the trusted namespace, but I haven't been able to find a namespace that I can mount and that does indeed allow for use of the trusted namespace.

Unfortunately, I'm unable to upgrade to a supported FreeBSD version. Additionally, while KOFS has a flag to read its opaque whiteout files from the user namespace instead of the trusted one, we're stuck building our KOFS on top of tempfs, which does not support user namespace extended attributes.

Any thoughts?

Answer 1

TL;DR: for your specific use case, you should use the system namespace.

FreeBSD's extattr(9) man page is being somewhat mealy-mouthed here, but what it actually means is that there are two standard attribute namespaces defined, user and system, but the filesystem API does technically allow others because it's just an integer. Linux's API is similarly open-ended, but four standard namespaces are defined even though others are technically allowed because they're just string prefixes to the name.

In both cases, what actually matters is which attributes are actually supported by the filesystems you are using, and the semantics. As you've already discovered, FreeBSD's tmpfs only supports system attributes.

Linux's "user" namespace maps directly to FreeBSD's user namespace (EXTATTR_NAMESPACE_USER, or 1). There can be some subtle differences in what is and is not allowed, and there are surprises for those expecting it to follow POSIX semantics based on the file's mode bits, but unprivileged users can generally expect to manipulate user attributes on their own files.

Linux's "security", "system" and "trusted" namespaces more or less map to FreeBSD's system namespace (EXTATTR_NAMESPACE_SYSTEM, or 2). These require elevated privileges to access: on Linux it depends on the specific namespace and attribute name, but the CAP_SYS_ADMIN capability is a good starting point; on FreeBSD it's the PRIV_VFS_EXTATTR_SYSTEM privilege.

The exact reasoning behind Linux having three system namespaces instead of one is probably lost to time, but I suspect it's that the kernel developers wanted to provide prefixes for various system components to avoid name collisions and this was considered the tidiest way to do it. (That non-kernel system attributes would still all get to fight it out under "trusted" probably didn't seem important at the time.)

For completeness, MacOS also has extended attributes. Its API is close to Linux, except that it's somewhat muddy when it comes to namespaces. Attributes tend to have a prefix such as "com.apple.", but this is merely a convention to avoid name collisions and the kernel pays little attention to it. Generally these are all in the user namespace unless you provide extra options such as XATTR_SHOWCOMPRESSION in which case some other names show up, some of which cannot even be accessed by root. Meanwhile, the less said about Solaris, the better.