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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




> -----Original Message-----
> From: Wolfgang Walter [mailto:wolfgang.walter@xxxxxxx]
> Sent: Tuesday, January 10, 2012 12:22 PM
> To: Myklebust, Trond
> Cc: Linus Torvalds; linux-nfs@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx
> 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@REALM
> > > server: foo@REALM => uid 600
> >
> > No. In the scenario you describe above, it will be
> 
> Sorry. Of course.
> 
> >
> > client: uid 600 <=> foo@REALM
> > server: foo@REALM <=> 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@REALM 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@REALM
> > client  bar@REALM => 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@REALM 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
��.n��������+%������w��{.n�����{��w���jg��������ݢj����G�������j:+v���w�m������w�������h�����٥



[Index of Archives]     [Linux Filesystem Development]     [Linux USB Development]     [Linux Media Development]     [Video for Linux]     [Linux NILFS]     [Linux Audio Users]     [Yosemite Info]     [Linux SCSI]

  Powered by Linux