RE: NFSv4 behaviour on unknown users

["Spencer Shepler" <spencer.shepler@gmail.com>]

> -----Original Message-----
> From: Trond Myklebust [mailto:Trond.Myklebust@netapp.com]
> Sent: Monday, November 29, 2010 3:16 PM
> To: Spencer Shepler
> Cc: Daniel.Muntz@emc.com; spelic@shiftmail.org; linux-nfs@vger.kernel.org
> Subject: RE: NFSv4 behaviour on unknown users
> 
> On Mon, 2010-11-29 at 14:57 -0800, Spencer Shepler wrote:
> > Dan,
> >
> > A change to the NFSv4.0 and NFSv4.1 RFCs is unnecessary.
> > What you suggest can be implemented today and still adhere to the RFC
> > text.  From RFC3530 (section 4.8) and RFC5661 (section 5.9) the
> > following text is quoted:
> >
> > "  In the case where there is no translation available to the client or
> >    server, the attribute value will be constructed without the "@".
> >    Therefore, the absence of the @ from the owner or owner_group
> >    attribute signifies that no translation was available at the sender
> >    and that the receiver of the attribute should not use that string as
> >    a basis for translation into its own internal format.  Even though
> >    the attribute value cannot be translated, it may still be useful.  In
> >    the case of a client, the attribute string may be used for local
> >    display of ownership.
> >
> >    To provide a greater degree of compatibility with NFSv3, which
> >    identified users and groups by 32-bit unsigned user identifiers and
> >    group identifiers, owner and group strings that consist of decimal
> >    numeric values with no leading zeros can be given a special
> >    interpretation by clients and servers that choose to provide such
> >    support.  The receiver may treat such a user or group string as
> >    representing the same user as would be represented by an NFSv3 uid or
> >    gid having the corresponding numeric value.  A server is not
> >    obligated to accept such a string, but may return an NFS4ERR_BADOWNER
> >    instead.  To avoid this mechanism being used to subvert user and
> >    group translation, so that a client might pass all of the owners and
> >    groups in numeric form, a server SHOULD return an NFS4ERR_BADOWNER
> >    error when there is a valid translation for the user or owner
> >    designated in this way.  In that case, the client must use the
> >    appropriate name@domain string and not the special form for
> >    compatibility."
> >
> >
> > I read this that if the implementation or administrator chooses to
> > op-out of the user@domain mapping, it may do so and the client and
> > server have a method available to them to communicate traditiona
> > uid/gid.
> >
> > So, all that is needed now it seems is some code to provide the option
> > to the admin or as you suggest, change the default.
> >
> > Spencer
> 
> It is way too late to change the default. All known existing NFSv4 servers
> would spit at you because they have been coded to match the above
> normative "SHOULD".

The intent of my email was to state that a change of the RFCs was
not required to build a solution that addresses the deployment
described.

It may be that the servers in question can be changed as easily
as the clients and therefore a solution is quite possible.

So, it is possible.  Now the question of probable is in play.

> 
> Without that option, you will also need a mechanism to allow the client
> and server to agree on a convention. Otherwise, admins have to go in and
> manually set the correct site default on all their clients and servers.

IIRC, the Solaris implementation will encode the uid/gid as
a simple "stringified" uid/gid without the "@".  Seems simple
enough and quite portable.  If the linux implementation were
to choose that as the default, others will follow.

Spencer

> 
> Trond
> 
> 
> > > -----Original Message-----
> > > From: linux-nfs-owner@vger.kernel.org [mailto:linux-nfs-
> > > owner@vger.kernel.org] On Behalf Of Daniel.Muntz@emc.com
> > > Sent: Monday, November 29, 2010 2:09 PM
> > > To: Trond.Myklebust@netapp.com; spelic@shiftmail.org
> > > Cc: linux-nfs@vger.kernel.org
> > > Subject: RE: NFSv4 behaviour on unknown users
> > >
> > > Looks like it's time for my annual numeric uid rant...
> > >
> > > IMHO this was the silliest decision in the v4 spec, and a frequent
> > > hindrance to users wanting to move from v3.  Once again, I'm going
> > > to suggest that the v4.x series officially support numeric uid/gid
> > > strings as first-class user identifiers, rather than trying to force
> > > "name@domain" on systems that do not need this functionality, and
> > > are worse off for having to support it.  The fact that every OS
> > > needs different configuration to get it working just adds to the
> > > insanity.  Supply something that works (numeric id strings) as the
> > > default, but allow the name@domain "enhancement" for those who want
> > > it.  Then, everything just works, people seamlessly migrate to v4.x,
> > > and world peace is achieved.  There could even be an option to
> > > disable numeric id string support for those vehemently opposed to
> > > its existence, but at least in this case sysadmins have to go out of
> > > their way to make their system return nobody/nogroup for all users,
> rather than being the default behavior.
> > >
> > >   -Dan
> > >
> > > -----Original Message-----
> > > From: linux-nfs-owner@vger.kernel.org [mailto:linux-nfs-
> > > owner@vger.kernel.org] On Behalf Of Trond Myklebust
> > > Sent: Monday, November 29, 2010 10:23 AM
> > > To: Spelic
> > > Cc: linux-nfs@vger.kernel.org
> > > Subject: Re: NFSv4 behaviour on unknown users
> > >
> > > On Mon, 2010-11-29 at 19:12 +0100, Spelic wrote:
> > > > Hello all
> > > > we recently moved to nfsv4 from v3.
> > > >
> > > > I'm currently using idmapd and not kerberos.
> > > >
> > > > I noticed that now, with idmapd (and with idmapd is the only way I
> > > > know for configuring nfsv4 for now), users that are not known at
> > > > server side are squashed to nobody / nogroup  (65534 / 65534).
> > > > And a chown by root from the client fails if the user is not known
> > > > at server side.
> > > >
> > > > That's a problem... now we need ldap everywhere...
> > > >
> > > > We were often using NFS for exporting some diskspace to machines
> > > > on an as-needed basis, so this new behaviour complicates the
> > > > things greatly for us :-/ It's almost easier to setup iSCSI
> > > > targets now :-((
> > > >
> > > > Is there a way to have nfsv4 with the behaviour of users of nfsv3,
> > > > that is, using numeric IDs instead of the names, like: "nfsserver,
> > > > don't care if you don't know the user, just give me the numeric ID
> > > > for
> > > the file..."
> > >
> > > No. That is not allowed by the spec.
> > >
> > > Trond
> > > --
> > > Trond Myklebust
> > > Linux NFS client maintainer
> > >
> > > NetApp
> > > Trond.Myklebust@netapp.com
> > > www.netapp.com
> > >
> > > --
> > > To unsubscribe from this list: send the line "unsubscribe linux-nfs"
> > > in the body of a message to majordomo@vger.kernel.org More majordomo
> > > info at http://vger.kernel.org/majordomo-info.html
> > >
> > > --
> > > To unsubscribe from this list: send the line "unsubscribe linux-nfs"
> > > in the body of a message to majordomo@vger.kernel.org More majordomo
> > > info at http://vger.kernel.org/majordomo-info.html
> >
> 
> --
> Trond Myklebust
> Linux NFS client maintainer
> 
> NetApp
> Trond.Myklebust@netapp.com
> www.netapp.com