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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

--
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

[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]
  Powered by Linux