Trond Myklebust | 9 Jan 20:45 2012
Picon

[PATCH] NFSv4: Change the default setting of the nfs4_disable_idmapping parameter

Now that the use of numeric uids/gids is officially sanctioned in
RFC3530bis, it is time to change the default here to 'enabled'.

By doing so, we ensure that NFSv4 copies the behaviour of NFSv3 when we're
using the default AUTH_SYS authentication (i.e. when the client uses the
numeric uids/gids as authentication tokens), so that when new files are
created, they will appear to have the correct user/group.
It also fixes a number of backward compatibility issues when migrating
from NFSv3 to NFSv4 on a platform where the server uses different uid/gid
mappings than the client.

Note also that this setting has been successfully tested against servers
that do not support numeric uids/gids at several Connectathon/Bakeathon
events at this point, and the fall back to using string names/groups has
been shown to work well in all those test cases.

Signed-off-by: Trond Myklebust <Trond.Myklebust@...>
---
 Documentation/kernel-parameters.txt |   17 +++++++++++------
 fs/nfs/client.c                     |    2 +-
 2 files changed, 12 insertions(+), 7 deletions(-)

diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
index 81c287f..dfd21cf 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
 <at>  <at>  -1630,12 +1630,17  <at>  <at>  bytes respectively. Such letter suffixes can also be entirely omitted.
 			The default is to return 64-bit inode numbers.

 	nfs.nfs4_disable_idmapping=
(Continue reading)

J. Bruce Fields | 22 Mar 21:47 2012

Re: [PATCH] NFSv4: Change the default setting of the nfs4_disable_idmapping parameter

By the way, I finally got around to looking at the server side.

We don't have any way to negotiate with the client--we don't get an
error back if the name we return in a getattr reply isn't one the client
likes--so I don't think I can default the new behavior to "on" without
breaking existing setups.

Other than that I think I'll just copy the client, module parameter and
all.  That allows us to do the numeric case in-kernel and avoid
polluting our mapping cache with lots of "obvious" 123<->"123" mappings.

(OK, maybe I shouldn't copy the same parameter name, though--even if it
works it might be confusing.)

(Untested.)

--b.

diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
index 0d79a88..aa90574 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
 <at>  <at>  -1686,6 +1686,14  <at>  <at>  bytes respectively. Such letter suffixes can also be entirely omitted.
 			The default is to send the implementation identification
 			information.

+	nfsd.nfs4_disable_idmapping=
+			[NFSv4] When set to to '1', the NFSv4 server
+			will return only numeric uids and gids to clients
+			using auth_sys, and will expect numeric uids and
(Continue reading)

Myklebust, Trond | 22 Mar 21:53 2012
Picon

Re: [PATCH] NFSv4: Change the default setting of the nfs4_disable_idmapping parameter

On Thu, 2012-03-22 at 16:47 -0400, J. Bruce Fields wrote:
> By the way, I finally got around to looking at the server side.
> 
> We don't have any way to negotiate with the client--we don't get an
> error back if the name we return in a getattr reply isn't one the client
> likes--so I don't think I can default the new behavior to "on" without
> breaking existing setups.
> 
> Other than that I think I'll just copy the client, module parameter and
> all.  That allows us to do the numeric case in-kernel and avoid
> polluting our mapping cache with lots of "obvious" 123<->"123" mappings.
> 
> (OK, maybe I shouldn't copy the same parameter name, though--even if it
> works it might be confusing.)

Does the idmapper do the right thing for numeric ids these days? If the
older clients are running a newer idmapper that can deal with numeric
ids, then even the legacy clients should be able to work cleanly.

Otherwise, there is also the alternative of making the whole thing a
per-client export option...

-- 
Trond Myklebust
Linux NFS client maintainer

NetApp
Trond.Myklebust <at> netapp.com
www.netapp.com


(Continue reading)

Myklebust, Trond | 22 Mar 22:01 2012
Picon

Re: [PATCH] NFSv4: Change the default setting of the nfs4_disable_idmapping parameter

On Thu, 2012-03-22 at 16:53 -0400, Trond Myklebust wrote:
> Does the idmapper do the right thing for numeric ids these days? If the
> older clients are running a newer idmapper that can deal with numeric
> ids, then even the legacy clients should be able to work cleanly.

If this isn't the case, then the older clients are broken anyway. The
server has always had the option of returning numeric ids if it has no
mapping from a uid/gid into an owner/group string.

IOW: the only difference between older and newer clients should really
be that the newer ones handle numeric strings more efficiently without
requiring an upcall, and that the newer clients will also try to _send_
numeric ids in SETATTR calls.

-- 
Trond Myklebust
Linux NFS client maintainer

NetApp
Trond.Myklebust <at> netapp.com
www.netapp.com


J. Bruce Fields | 22 Mar 22:26 2012

Re: [PATCH] NFSv4: Change the default setting of the nfs4_disable_idmapping parameter

On Thu, Mar 22, 2012 at 09:01:12PM +0000, Myklebust, Trond wrote:
> On Thu, 2012-03-22 at 16:53 -0400, Trond Myklebust wrote:
> > Does the idmapper do the right thing for numeric ids these days? If the
> > older clients are running a newer idmapper that can deal with numeric
> > ids, then even the legacy clients should be able to work cleanly.
> 
> If this isn't the case, then the older clients are broken anyway. The
> server has always had the option of returning numeric ids if it has no
> mapping from a uid/gid into an owner/group string.

Hm, yes, but I was worried that the id<->name mapping might just be
different on the two sides--but if that's so, and they were using
auth_sys, then they likely already had problems.

So, maybe we could default this to on.

If that's the case then I'd rather not bother making this per export:
just an option to get the server back to its previous behavior would
seem enough.

--b.

> IOW: the only difference between older and newer clients should really
> be that the newer ones handle numeric strings more efficiently without
> requiring an upcall, and that the newer clients will also try to _send_
> numeric ids in SETATTR calls.
> 
> -- 
> Trond Myklebust
> Linux NFS client maintainer
(Continue reading)

Boaz Harrosh | 22 Mar 23:11 2012

Re: [PATCH] NFSv4: Change the default setting of the nfs4_disable_idmapping parameter

On 03/22/2012 02:26 PM, J. Bruce Fields wrote:
> On Thu, Mar 22, 2012 at 09:01:12PM +0000, Myklebust, Trond wrote:
>> On Thu, 2012-03-22 at 16:53 -0400, Trond Myklebust wrote:
>>> Does the idmapper do the right thing for numeric ids these days? If the
>>> older clients are running a newer idmapper that can deal with numeric
>>> ids, then even the legacy clients should be able to work cleanly.
>>
>> If this isn't the case, then the older clients are broken anyway. The
>> server has always had the option of returning numeric ids if it has no
>> mapping from a uid/gid into an owner/group string.
> 
> Hm, yes, but I was worried that the id<->name mapping might just be
> different on the two sides--but if that's so, and they were using
> auth_sys, then they likely already had problems.
> 
> So, maybe we could default this to on.
> 
> If that's the case then I'd rather not bother making this per export:
> just an option to get the server back to its previous behavior would
> seem enough.
> 
> --b.
> 
>> IOW: the only difference between older and newer clients should really
>> be that the newer ones handle numeric strings more efficiently without
>> requiring an upcall, and that the newer clients will also try to _send_
>> numeric ids in SETATTR calls.
>>

I was thinking about this too. Trond was making this clearer. 
(Continue reading)

Boaz Harrosh | 22 Mar 23:16 2012

Re: [PATCH] NFSv4: Change the default setting of the nfs4_disable_idmapping parameter

On 03/22/2012 03:11 PM, Boaz Harrosh wrote:
> I fail to see an opposite scenario where
> the brokenness was good, and now it will be bad.
> 

I might be wrong in this regard, Though. I'm not totally
on top of all the possible cases.

Is there a way to Bata test this on large setups? What
if you make the default Kconfig(urable) so DISTROs can
compile with a new default and have a large scale testing
like in a rawhide version.

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

J. Bruce Fields | 26 Mar 17:36 2012

Re: [PATCH] NFSv4: Change the default setting of the nfs4_disable_idmapping parameter

On Thu, Mar 22, 2012 at 03:16:42PM -0700, Boaz Harrosh wrote:
> On 03/22/2012 03:11 PM, Boaz Harrosh wrote:
> > I fail to see an opposite scenario where
> > the brokenness was good, and now it will be bad.
> > 
> 
> I might be wrong in this regard, Though. I'm not totally
> on top of all the possible cases.
> 
> Is there a way to Bata test this on large setups? What
> if you make the default Kconfig(urable) so DISTROs can
> compile with a new default and have a large scale testing
> like in a rawhide version.

That'll be easy enough to patch if it turns out to be useful.

But if we're going to default to on, then let's keep it simple for now.
And increase the chance that we get any complaints early.

So I flipped the default, added a missing fallback in the case the
client gives us a name when we're expecting a number, and tested.

And decided to keep the same parameter name as on the client after all,
since it really does do pretty much the same thing.

Comitting for 3.4 absent objections.

--b.

commit 3516a947e59fb635ddd5c42d70bd4274f61daa8a
(Continue reading)

J. Bruce Fields | 22 Mar 22:09 2012

Re: [PATCH] NFSv4: Change the default setting of the nfs4_disable_idmapping parameter

On Thu, Mar 22, 2012 at 08:53:25PM +0000, Myklebust, Trond wrote:
> On Thu, 2012-03-22 at 16:47 -0400, J. Bruce Fields wrote:
> > By the way, I finally got around to looking at the server side.
> > 
> > We don't have any way to negotiate with the client--we don't get an
> > error back if the name we return in a getattr reply isn't one the client
> > likes--so I don't think I can default the new behavior to "on" without
> > breaking existing setups.
> > 
> > Other than that I think I'll just copy the client, module parameter and
> > all.  That allows us to do the numeric case in-kernel and avoid
> > polluting our mapping cache with lots of "obvious" 123<->"123" mappings.
> > 
> > (OK, maybe I shouldn't copy the same parameter name, though--even if it
> > works it might be confusing.)
> 
> Does the idmapper do the right thing for numeric ids these days? If the
> older clients are running a newer idmapper that can deal with numeric
> ids, then even the legacy clients should be able to work cleanly.

If at all possible I really don't want to break clients, even if they
have an easy fix.  (Or maybe I wasn't understanding what you were
suggesting.)

> Otherwise, there is also the alternative of making the whole thing a
> per-client export option...

Hm, maybe that'd be better.

We're currently mapping names to id's when we decode the xdr--before
(Continue reading)

J. Bruce Fields | 22 Mar 21:54 2012

Re: [PATCH] NFSv4: Change the default setting of the nfs4_disable_idmapping parameter

On Thu, Mar 22, 2012 at 04:47:05PM -0400, bfields wrote:
> By the way, I finally got around to looking at the server side.
> 
> We don't have any way to negotiate with the client--we don't get an
> error back if the name we return in a getattr reply isn't one the client
> likes--so I don't think I can default the new behavior to "on" without
> breaking existing setups.

But we should still be able to make this effectively the default on new
server installations:  maybe:

	- Have the new module parameter be set based on a new
	  "ServerNumericMapping" variable in idmapd.conf defaults to
	  off.
	- Set it to "on" in the example idmapd.conf we distribute
	  upstream, and encourage distributions to do the same in the
	  idmapd.conf they install by default.

--b.

> 
> Other than that I think I'll just copy the client, module parameter and
> all.  That allows us to do the numeric case in-kernel and avoid
> polluting our mapping cache with lots of "obvious" 123<->"123" mappings.
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html

(Continue reading)


Gmane