Re: migration from svcgssd to gssproxy results in regression.

[Scott Mayhew <smayhew@redhat.com>]

Hi Neil,

On Wed, 08 Mar 2017, NeilBrown wrote:

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

Are using SSSD by any chance?  I had a similar issue in RHEL maybe a
year ago.  If you're using SSSD there's a localauth plugin that needs to
be enabled that will cause krb5_aname_to_localname() (which is called by
gss_localname()) to return a fully-qualified username instead of the
short username.

-Scott

>  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