From: James Morris Subject: Re: [PATCH 0/4][RFC] NFSv3: implement extended attribute (XATTR) protocol Date: Wed, 14 Oct 2009 15:30:44 +1100 (EST) Message-ID: References: <4ACB5FC0.7060307@redhat.com> <4AD36C82.8080904@redhat.com> <4AD384BE.2090008@redhat.com> <1255388158.3711.57.camel@heimdal.trondhjem.org> <1255458444.3711.113.camel@heimdal.trondhjem.org> <4AD53200.1010100@schaufler-ca.com> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Trond Myklebust , Peter Staubach , Tom Haynes , "J. Bruce Fields" , "linux-nfs@vger.kernel.org" , Christoph Hellwig , "linux-fsdevel@vger.kernel.org" , David Patrick Quigley , Tyler Hicks , Dustin Kirkland To: Casey Schaufler Return-path: In-Reply-To: <4AD53200.1010100@schaufler-ca.com> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Tue, 13 Oct 2009, Casey Schaufler wrote: > If you wanted to you could implement a mapping scheme of your choice > on the server. Just as long as you don't expect any defined semantics from this protocol -- it's purely xattr transport. > A Smack server might be happy with mapping > nfs.security.SMACK64 to security.SMACK64, while an HP/UX server might > have a function to map nfs.security.selinux into security.BellAndLaPadula > for its own nefarious purposes. Because you could do this strictly > on the server you don't have to implement a negotiation protocol, > although you could. I think if we start looking at negotiation & interpretation, then we've moved beyond simple metadata transport and should be looking at extending NFSv4 instead (e.g. like Labeled NFS). - James -- James Morris