[lkml]   [2012]   [Jan]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [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@REALM
    > server: foo@REALM => uid 600

    No. In the scenario you describe above, it will be

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

    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.

    When I use KerberosV principals ('kinit trond@REALM') as my
    authentication token in an RPCSEC_GSS session, then I want to use the
    same _string_ user trond@REALM to label my file ownership. The idmapper
    is then used to map the abstract trond@REALM 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

    Trond Myklebust
    Linux NFS client maintainer


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2012-01-10 14:41    [W:0.027 / U:15.196 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site