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]

Message-ID: <2E1EB2CF9ED1CB4AA966F0EB76EAB4430CCB0A22@SACMVEXC2-PRD.hq.netapp.com>
Date:	Tue, 10 Jan 2012 09:47:42 -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: Tuesday, January 10, 2012 12:22 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
> 
> Am Dienstag, 10. Januar 2012 schrieb Trond Myklebust:
> > On Tue, 2012-01-10 at 11:53 +0100, Wolfgang Walter wrote:
> > > Am Dienstag, 10. Januar 2012 schrieb Trond Myklebust:
> > > > On Tue, 2012-01-10 at 01:49 +0100, Wolfgang Walter wrote:
> > > > > On Monday 09 January 2012, Trond Myklebust wrote:
> > > > > > On Mon, 2012-01-09 at 14:28 -0800, Myklebust, Trond wrote:
> > > > > > > > -----Original Message-----
> > > > > > >
> > > > > > > Please read the changelog and documentation:
> > > > > > >
> > > > > > > If your server doesn’t support numeric uids/gids, then you
> > > > > > > will see _no_ change in behaviour.
> > > > >
> > > > > Hmm, what does that mean exactly? Does a linux nfs4-server
> > > > > support numeric uids/gids? If yes, by default or do I need do set an
> option?
> > > >
> > > > The patch requires no changes to a configuration that is already
> > > > working. That's the whole point I've been trying to get across.
> > >
> > > So if user foo has uid 500 on the server and uid 600 on the client
> > > that will still work with AUTH_SYS:
> > >
> > > client: uid 500 => foo@...LM
> > > server: foo@...LM => uid 600
> >
> > No. In the scenario you describe above, it will be
> 
> Sorry. Of course.
> 
> >
> > client: uid 600 <=> foo@...LM
> > server: foo@...LM <=> uid 500
> >
> > > and vice-versa?
> >
> > The above _not_ work properly in the existing code... This kind of
> > situation is the whole reason for wanting to change the existing code.
> >
> > With the existing code, the client will send numeric uid 600 as part
> > of the rpc-level AUTH_SYS authentication, and so the server will
> > create files with uid 600 irrespective of the foo@...LM idmapping at
> > the NFSv4 level.
> > When the client later attempts to do a GETATTR on that file, the
> > server will then translate that uid 600 using the idmapper
> >
> > server  uid 600 => bar@...LM
> > client  bar@...LM => uid 213412
> >
> > IOW: This is exactly the situation where we want to use numeric uids
> > everywhere, so that the server returns a numeric uid 600 in the GETATTR.
> > In addition, if the client does a 'chown foo', it should send uid 600
> > in the SETATTR request, which matches the uid 600 in the AUTH_SYS
> > authentication.
> 
> We are using AUTH_SYS for exporting read-only.
> 
> The uid (and gids) of the users accessing the filesystem (that is our idenitities
> used with SYS_AUTH) are synced. But there are other identities which are
> not. Debian i.e. allocates some system uids and gids dynamically.
> 
> With this change access to files and directories will not break but i.e. if you
> use cp as root cp will behave differently. I.e. as part of our installation
> process we once mounted a filesystem ro and cloned it with cp -a .... This
> would break.

You will get an exact replica of the server filesystem, just as if you had used NFSv3.

> > Or again: If I'm using AUTH_SYS, then I'm transmitting numeric
> > uids/gids as my authentication token, and so I want to use the same
> > numeric uids/gids to label my file ownership. The idmapper doesn't
> > affect the AUTH_SYS authentication token, and so mapping the NFS
> > ownership to trond@...LM is not useful and may instead result in wrong
> > behaviour such as in the situation described above.
> 
> So this basically says that idmapper will not be used for AUTH_SYS any more
> and behaves exactly as NFSv3?

Yes
-  NFSv3 got the behaviour with AUTH_SYS right, but RPCSEC_GSS is broken.
- The original NFSv4 protocol text got the behaviour with RPCSEC_GSS right, but AUTH_SYS is broken.

This change means that NFSv4 finally gets both AUTH_SYS _and_ RPCSEC_GSS right. It make the NFS protocol use principal-like names when principals are used as the basis for authentication, and numeric uid/gids when those are used as the basis for authentication. It ensures that acls and mode bit-based permissions always work as expected...

Trond