Re: git: c33509d49a6f - main - gssd: Fix handling of the gssname=<name> NFS mount option

On Sat, Jan 7, 2023 at 1:50 PM Rick Macklem <rmacklem@freebsd.org> wrote:

> The branch main has been updated by rmacklem:
>
> URL:
> https://cgit.FreeBSD.org/src/commit/?id=c33509d49a6fdcf86ef280a78f428d3cb7012c4a
>
> commit c33509d49a6fdcf86ef280a78f428d3cb7012c4a
> Author:     Rick Macklem <rmacklem@FreeBSD.org>
> AuthorDate: 2023-01-07 21:49:25 +0000
> Commit:     Rick Macklem <rmacklem@FreeBSD.org>
> CommitDate: 2023-01-07 21:49:25 +0000
>
>     gssd: Fix handling of the gssname=<name> NFS mount option
>
>     If an NFS mount using "sec=krb5[ip],gssname=<name>" is
>     done, the gssd daemon fails.  There is a long delay
>     (several seconds) in the gss_acquire_cred() call and then
>     it returns success, but the credentials returned are
>     junk.
>
>     I have no idea how long this has been broken, due to some
>     change in the Heimdal gssapi library call, but I suspect
>     it has been quite some time.
>
>     Anyhow, it turns out that replacing the "desired_name"
>     argument with GSS_C_NO_NAME fixes the problem.
>     Replacing the argument should not be a problem, since the
>     TGT for the host based initiator credential in the default
>     keytab file should be the only TGT in the gssd'd credential
>     cache (which is not the one for uid 0).
>
>     I will try and determine if FreeBSD13 and/or FreeBSD12
>     needs this same fix and will MFC if they need the fix.
>
>     This problem only affected Kerberized NFS mounts when the
>     "gssname" mount option was used.  Other Kerberized NFS
>     mount cases already used GSS_C_NO_NAME and work ok.
>     A workaround if you do not have this patch is to do a
>     "kinit -k host/FQDN" as root on the machine, followed by
>     the Kerberized NFS mount without the "gssname" mount
>     option.
>
>

Hi Rick,

This doesn't seem like a good long-term fix.
If we're going to have a gssname argument, we should actually make
it take effect, rather than silently ignoring it, which is what using
GSS_C_NO_NAME
does (it indicates the use of "any credential", which ends up meaning the
default credential when used on a GSS initiator).

It should be possible to inspect the "junk" credential from
gss_acquire_cred()
and learn more about what happened (perhaps a non-kerberos mechanismm was
picked, or the name was in the wrong format)  using various gss_inquire_*()
calls,
as a diagnostic measure.  Unfortunately I don't anticipate having a huge
amount of time
to put into it anytime soon...

Thanks,

Ben