NAs are a non-starter here for a couple of reasons.
1. They are specified as being user managed and opaque to NFS. MAC
labels are typically set by the OS, and may only be set by the user when
permitted by MAC policy. The labels need to be interpreted by the OS to
allow MAC policy to be enforced.
2. The NA namespace is arbitrary and opaque to the OS. There's no scope
in NFSv4 design to allow a namespace to be specified for e.g. MAC labels,
and trying to modify the spec to allow it seems impractical to me. It
would at the very least break backward compatibility with clients and
servers, and lead to some ugly hacks to try and ensure that systems were
reliably speaking to peers which understood the namespace.
It might be possible to implement Linux/BSD style xattrs for NFSv4,
assuming that the IETF folk would approve of the idea, but I don't think
this is really the right solution for conveying MAC labels across the
wire. The xattr API as a local interface is pretty good for this (as it
is FS independent, simple, and established), but that does not
automatically translate to an xattr wire protocol being the right thing.
The problem with this, I believe, is that you end up with quite a lot of
overhead and complexity being added to NFSv4 which does not actually meet
the requirements of MAC labeling, and like NAs, seems more suited
for arbitrary user-managed metdata.
Using RAs for MAC labels seems most appropriate, as they're simple,
extensible and already used for similar protocol attributes such as ACLs,
and other system-managed metadata.
- James
--
James Morris
<jmorris@namei.org>
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
