Re: [nfsv4] No WG meeting for IETF 91

[David Noveck <[e-mail]>]

I agree with Bruce's basic point, but have trouble with the following:

>    (For example, some systems use xattr operations to set and query
>    ACLs.)

Given that NFSv4 has ACL's, this statement might lead to a discussion that
is really beside-the-point for user xattr's.  Can we say "security-related
attributes".

On Sat, Oct 4, 2014 at 4:37 PM, Manoj Naik <[e-mail]> wrote:

> "nfsv4" <[e-mail]> wrote on 10/04/2014 12:03:39 PM:
>
> > From: "J. Bruce Fields" <[e-mail]>
> > To: Chuck Lever <[e-mail]>
> > Cc: Christoph Hellwig <[e-mail]>, "[e-mail]" <[e-mail]>
> > Date: 10/04/2014 12:03 PM
> > Subject: Re: [nfsv4] No WG meeting for IETF 91
> > Sent by: "nfsv4" <[e-mail]>
> >
> > On Sat, Oct 04, 2014 at 12:04:54PM -0400, Chuck Lever wrote:
> > >
> > > On Oct 4, 2014, at 3:11 AM, Christoph Hellwig <[e-mail]> wrote:
> > >
> > > > 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.
> > >
> > > I thought we had already agreed that only the “user.” namespace would
> > > be exposed via NFS. If that’s not in the draft specification, it really
> > > needs to be added.
> >
> > Section 3 does say that the "user" namespace is the only one for which
> > xattrs operations "can be considered interoperable across platforms and
> > vendor implementations", so it seems strange if they're trying to keep
> > the others.
>
> Definitely not trying to keep the others. But, based on what I thought was
> a request, leaving open the option of allowing xattrs from other namespaces
> to be added in the future if they could be made interoperable.
>
> >
> > I think they were trying to keep NFS xattr names the same as local
> > attribute names instead of requiring implementations to strip the
> > "user.", and also maybe hoping to leave open the possibility of future
> > standardization of behavior in other namespaces without requiring new
> > xdr.  But I think all the feedback has been that that's a quagmire.
>
> Yes.
>
> >
> > So I'm not sure what the appropriate language is.  Maybe something
> > roughly like:
> >
> >    Some operating systems define multiple "namespaces" for xattrs,
> >    with the system enforcing different policies for different
> >    xattrs, and giving some xattrs special meaning to the system.
> >    (For example, some systems use xattr operations to set and query
> >    ACLs.)
> >
> >    NFS extended attributes are not organized into namespaces and do
> >    not have special meaning to the server.  Several operating
> >    systems that define multiple namespaces have a "user" namespace
> >    with these semantics.  Such systems will want to keep NFS
> >    extended attributes under the "user" namespace by translating
> >    any NFS xattr name "X" to a local extended attribute name
> >    "user.X".
>
> I can go with this.
>
> Manoj.
>
> >
> > --b.
> >
> > _______________________________________________
> > nfsv4 mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/nfsv4
>
> _______________________________________________
> nfsv4 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/nfsv4
>
>