> -----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�����٥
