migration from svcgssd to gssproxy results in regression.

[NeilBrown <neilb@suse.com>]

[-- Attachment #1: Type: text/plain, Size: 1291 bytes --]


Hi,
 I recently tried using gssproxy for krb5 authentication with nfsd.
 This was because customer is using an AD kerberos master which uses
 certificates which are too big for svcgssd to work with (i.e. larger
 than one page).

 Unfortunately it doesn't work.

 The svcgssd code in nfs-utils calls
   gss_display_name()
 to get the name of the principal.  This returns something like
 "user@domain".

 getpwnam() works perfectly on this (when nsswitch is set to use "winbind")
 but svcgssd goes further and uses nfs4_gss_princ_to_ids() to perform
 the lookup.  Presumably this is more general?

 gssproxy does neither of these.
 It uses gss_localname() to get the user name, which returns something
 like "user".
 It then calls getpwnam() on that, which fails ("user@domain" or
 "domain\user" both succeed).

 I have modified my copy to use gss_display_name() instead of
 gss_localname() and it now appears to work perfectly ... for this
 use-case at least.

 What is the right way forward here?
 Is nfs4_gss_princ_to_ids() really necessary?
 Should gssproxy use it, at least for requests from the NFS server?
 Is there are good reason not to use gss_display_name() uniformly?
 Maybe use gss_local_name(), and it that fails, or getpwnam fails,
 use gss_display_name()??

Thanks,
NeilBrown

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]