On Sat, Jan 7, 2023 at 6:04 PM Benjamin Kaduk <bjkf...@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 > ith...@uoguelph.ca > > On Sat, Jan 7, 2023 at 1:50 PM Rick Macklem <rmack...@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 <rmack...@freebsd.org> >> AuthorDate: 2023-01-07 21:49:25 +0000 >> Commit: Rick Macklem <rmack...@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
