On Thu, 28 Feb 2008, Dave Quigley wrote: > There are several things here. I've spoken to several people about this > and the belief I've gotten from most of them is that a recommended > attribute is how this is to be transported. The NFSv4 spec people will > probably say that if you want xattr like functionality for NFSv4 use > named attributes. 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@xxxxxxxxx> -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
