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). > The gssname argument still does take effect. The code in gssd.c does essentially a "kinit -k <name>" into a specific credential cache (/tmp/krb5cc_gssd or close to that). Then the gss_acquire_cred() uses that credential cache, which should never have any other TGT in it.
> 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... I suspect the problem might be that "desired_name" appears to be in the Kerberos form (host/nfs-client.domain) and not the GSSAPI form (host@nfs-client.domain), but I'm not sure how the code in gssd.c could change it? Maybe it can (re)import the name after replacing the '/' with a '@', but I have not tried this. As above, I think the fix is ok, rick > > Thanks, > > Ben
