Re: [PATCH 0/4][RFC] NFSv3: implement extended attribute (XATTR) protocol

[Peter Staubach <staubach-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>]

Casey Schaufler wrote:
> James Morris wrote:
>> 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.
>>   
> 
> I agree completely. My point is that you can leave it up to the
> server to deal with if it is so inclined. No networking required.
> 
>>   
>>> 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).
>>   
> 
> Again, I agree. The appeal to this xattr approach is that there
> is no negotiation. It is just transport and storage. And for those
> who question the value of the scheme, it has been in use in Irix
> for -I'm not 100% sure- 10 years now.
> 

We need something like this support and this design is sufficient
to meet the current set of needs.  Let's not go too far, trying to
solve problems which do not need to be solved.

	Thanx...

		ps
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html