On Tue, 2009-10-13 at 18:02 +1100, James Morris wrote: > This xattr approach would only cover the "dumb server" scenario, where the > server simply stores and retrieves security labels on behalf of the > client. It's intended primarily to enable things like nfsroot, backups, > serving virtualized file systems etc., and not for fully trusted sharing > like Labeled NFS. > > It is essentially just security label transport. > > Support for this feature would be configured at the server, possibly an > option in /etc/exports which enables specific security namespaces, e.g: > > /opt/share 10.0.0.0/8(rw,insecure,xattr="user.*,security.SMACK64") > > This says that the XATTR side protocol is enabled and clients can read and > write user and security.smack xattrs (local DAC would be applied to both). > > The server kernel would likely need to know that these are foreign labels, > and not necessarily 'trust' them for its own use, so a root_squash -like > option may be used to remap them to an 'untrusted' local label for local > enforcement purposes -- if it was running SELinux or Smack at all, which > it may not be. Fair enough. That might indeed work. One simple alternative might be to just store the exported xattrs in something other than the 'security' extended attribute namespace so that your server processes don't have to deal with any conflicts. IOW: maybe add a 'nfs.security' xattr namespace, which would contain those security labels that are actually exported by this XATTR protocol, and which the clients could then translate into their local 'security' labels. You might even be able to store per-client security labels as something like 'nfs.$(hostname).security', or perhaps have a namespace like 'nfs.fedora11.security' that applies to all clients running fedora? > At the top of my todo list is to document the XATTR protocol -- I'll also > draft a specification for the security namespace along these lines. Thanks! That would be good. Trond -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
