Re: [nfsv4] No WG meeting for IETF 91

On 10/4/2014 3:11 AM, Christoph Hellwig wrote:
> On Sat, Oct 04, 2014 at 12:24:30AM -0400, Thomas Haynes wrote:
>> The argument being presented is that we should support xattrs
>> because they are there.
>>
>> What drives us to take the work? Where do we lose "customers"
>> if we do not do xattrs?
>
> That didn't seem to matter when adding named attribute support to
> NFSv4 :)  Not that I'm arguing for adding extattrs, especially in
> the form of the draft, but it seems like the standards fortunately
> are higher now.
>
>> What is the use case that makes us want to do it?
>>
>> How do different client OSes interact?
>> a) In namespaces
>> b) Securely
>> c) With the limits
>
> As someone who has worked with Linux xattrs for a long time, I think
> the Linux concept of the text prefixes for nightmares which have
> semantic meanings is a nightmare.  I don't really understand why and
> how it made it into Linux, as the original IRIX version had binary
> namespaces, as does FreeBSD.
>
> The current version of draft-naik-nfsv4-xattrs-01 totally ignores
> the issue of access control to different namespaces.  To be actually
> interoperable between Linux, FreeBSD, MacOS and Window (and more theoretically
> OS/2 and IRIX) it should be defined to operate on only what Linux calls
> "user." xattrs, FreeBSD calls EXTATTR_NAMESPACE_USER extattrs, IRIX calls
> user namespace attrs, and the the only one available to the rest.
>
> If we actually expose the Linux prefixes we create a giant inteoperability
> problem with unspecified mappings, including an expectation of Linux clients
> that they could store the attribute types that have security implications
> on servers that can not enforce anything like that.
>

I agree with this and I would pretty vocal in my stance against 
exporting security.* The security.* and trusted.* namespaces shouldn't 
be seen outside of the local box.

> Note that all of the kernel-implemented Linux xattrs in these namespaces
> are a blatant abuse of the xattr user interface and should have used
> different system calls as they don't have binary blob semantics, so if
> we plant to support them in NFSv4 they should probably be different
> operations.  All the important cases are already handled in a way more
> (labels) or less (ACLs) suitable already.
>
> _______________________________________________
> nfsv4 mailing list
> nfsv4@ietf.org
> https://www.ietf.org/mailman/listinfo/nfsv4
>