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] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 10 Jan 2012 08:38:53 -0500
From:	Trond Myklebust <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

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

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.

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.

When I use KerberosV principals ('kinit trond@...LM') as my
authentication token in an RPCSEC_GSS session, then I want to use the
same _string_ user trond@...LM to label my file ownership. The idmapper
is then used to map the abstract trond@...LM into a uid/gid that the
kernel can understand (and the actual value on the client/server is
irrelevant as long as it matches whatever the authentication token maps
to).

-- 
Trond Myklebust
Linux NFS client maintainer

NetApp
Trond.Myklebust@...app.com
www.netapp.com

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/