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]

Message-Id: <201201101822.21157.wolfgang.walter@stwm.de>
Date:	Tue, 10 Jan 2012 18:22:20 +0100
From:	Wolfgang Walter <wolfgang.walter@...m.de>
To:	Trond Myklebust <Trond.Myklebust@...app.com>
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

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. 

>
> 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?

>
> 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).


Regards,
-- 
Wolfgang Walter
Studentenwerk München
Anstalt des öffentlichen Rechts
--
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/