Re: git: c33509d49a6f - main - gssd: Fix handling of the gssname=<name> NFS mount option
Date: Thu, 12 Jan 2023 03:01:17 UTC
On Sat, Jan 7, 2023 at 6:04 PM Benjamin Kaduk <bjkfbsd@gmail.com> wrote: > > CAUTION: This email originated from outside of the University of Guelph. Do not click links or open attachments unless you recognize the sender and know the content is safe. If in doubt, forward suspicious emails to IThelp@uoguelph.ca > > 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). > I have reverted this patch. I found out that the long delay was caused by a misconfigured DNS (I did not have "dns" in /etc/nsswitch.conf, but did have a /etc/resolv.conf file and no route to the DNS server). I have done another commit which increases the timeout for the kernel to gssd(8) daemon upcall so that the mount does complete after about 30 seconds for this case of a misconfigured DNS and the gssd(8) daemon no longer terminates due to an upcall timeout. Thanks go to Ben for indicating that this needed further investigation. rick > 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