linux-kernel - RE: [GIT PULL] Please pull NFS client bugfixes and cleanups

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Mon, 9 Jan 2012 14:28:48 -0800
From:	"Myklebust, Trond" <Trond.Myklebust@...app.com>
To:	"Wolfgang Walter" <wolfgang.walter@...m.de>
Cc:	"Linus Torvalds" <torvalds@...ux-foundation.org>,
	<linux-nfs@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Subject: RE: [GIT PULL] Please pull NFS client bugfixes and cleanups

> -----Original Message-----
> From: Wolfgang Walter [mailto:wolfgang.walter@...m.de]
> Sent: Monday, January 09, 2012 5:15 PM
> To: Myklebust, Trond
> Cc: Linus Torvalds; linux-nfs@...r.kernel.org; linux-kernel@...r.kernel.org
> Subject: Re: [GIT PULL] Please pull NFS client bugfixes and cleanups
> 
> On Monday 09 January 2012, Trond Myklebust wrote:
> > Hi Linus,
> >
> > Please pull from the "nfs-for-3.3" branch of the repository at
> >
> >    git pull git://git.linux-nfs.org/projects/trondmy/linux-nfs.git
> > nfs-
> for-3.3
> >
> > This will update the following files through the appended changesets.
> >
> >   Cheers,
> >     Trond
> >
> >
> > commit 074b1d12fe2500d7d453902f9266e6674b30d84c
> > Author: Trond Myklebust <Trond.Myklebust@...app.com>
> > Date:   Mon Jan 9 13:46:26 2012 -0500
> >
> >     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@...app.com>
> >
> 
> 
> Does this mean that one has to modify all one's clients to get the old
> behaviour?
> 
> I'm not sure if this is a really good idea. I don't see the advantage. This will
> break a lot of existing installations when upgrading to >=3.3. And someone
> migrating from NFSv3 to NFSv4 has to give some thoughts to it anyway.

Please read the changelog and documentation:

If your server doesn’t support numeric uids/gids, then you will see _no_ change in behaviour.

If your server does support numeric uids/gids, and has the same mapping between numeric uids/gids and username/groupname as your clients, then you will see _no_ change in behaviour.

If your server does support numeric uids/gids, but the mapping between numeric uids/gids and username/groupname differs between server and client (e.g.. uid=20 maps to different users on the client and server) then you already had a problem in that creating the file using NFSv4 would result in you seeing the wrong owner and/or group. If this case, and this case only, the change to nfs4_disable_idmapper will result in you now seeing the correct owner/group for these files (just as if you were using NFSv3).

IOW: the only people who will want to use the old setting are those with broken servers that return incorrect errors when confronted with a numeric uid/gid. We have found no evidence that any such servers exist during the last full year of testing.

Trond