Date: Sat, 7 Jan 2023 18:03:55 -0800 From: Benjamin Kaduk <bjkfbsd@gmail.com> To: Rick Macklem <rmacklem@freebsd.org> Cc: src-committers@freebsd.org, dev-commits-src-all@freebsd.org, dev-commits-src-main@freebsd.org Subject: Re: git: c33509d49a6f - main - gssd: Fix handling of the gssname=<name> NFS mount option Message-ID: <CAJ5_RoA0YQQ8R59M8nSkFaTz6T%2BjWMnyxZjGT4PZn-kn_SpzXQ@mail.gmail.com> In-Reply-To: <202301072150.307LokNm093592@gitrepo.freebsd.org> References: <202301072150.307LokNm093592@gitrepo.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--000000000000c531cc05f1b71015 Content-Type: text/plain; charset="UTF-8" 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 --000000000000c531cc05f1b71015 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div dir=3D"ltr">On Sat, Jan 7, 2023 at 1:50 PM Rick Mackl= em <<a href=3D"mailto:rmacklem@freebsd.org">rmacklem@freebsd.org</a>>= wrote:<br></div><div class=3D"gmail_quote"><blockquote class=3D"gmail_quot= e" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204)= ;padding-left:1ex">The branch main has been updated by rmacklem:<br> <br> URL: <a href=3D"https://cgit.FreeBSD.org/src/commit/?id=3Dc33509d49a6fdcf86= ef280a78f428d3cb7012c4a" rel=3D"noreferrer" target=3D"_blank">https://cgit.= FreeBSD.org/src/commit/?id=3Dc33509d49a6fdcf86ef280a78f428d3cb7012c4a</a><b= r> <br> commit c33509d49a6fdcf86ef280a78f428d3cb7012c4a<br> Author:=C2=A0 =C2=A0 =C2=A0Rick Macklem <rmacklem@FreeBSD.org><br> AuthorDate: 2023-01-07 21:49:25 +0000<br> Commit:=C2=A0 =C2=A0 =C2=A0Rick Macklem <rmacklem@FreeBSD.org><br> CommitDate: 2023-01-07 21:49:25 +0000<br> <br> =C2=A0 =C2=A0 gssd: Fix handling of the gssname=3D<name> NFS mount op= tion<br> <br> =C2=A0 =C2=A0 If an NFS mount using "sec=3Dkrb5[ip],gssname=3D<name= >" is<br> =C2=A0 =C2=A0 done, the gssd daemon fails.=C2=A0 There is a long delay<br> =C2=A0 =C2=A0 (several seconds) in the gss_acquire_cred() call and then<br> =C2=A0 =C2=A0 it returns success, but the credentials returned are<br> =C2=A0 =C2=A0 junk.<br> <br> =C2=A0 =C2=A0 I have no idea how long this has been broken, due to some<br> =C2=A0 =C2=A0 change in the Heimdal gssapi library call, but I suspect<br> =C2=A0 =C2=A0 it has been quite some time.<br> <br> =C2=A0 =C2=A0 Anyhow, it turns out that replacing the "desired_name&qu= ot;<br> =C2=A0 =C2=A0 argument with GSS_C_NO_NAME fixes the problem.<br> =C2=A0 =C2=A0 Replacing the argument should not be a problem, since the<br> =C2=A0 =C2=A0 TGT for the host based initiator credential in the default<br= > =C2=A0 =C2=A0 keytab file should be the only TGT in the gssd'd credenti= al<br> =C2=A0 =C2=A0 cache (which is not the one for uid 0).<br> <br> =C2=A0 =C2=A0 I will try and determine if FreeBSD13 and/or FreeBSD12<br> =C2=A0 =C2=A0 needs this same fix and will MFC if they need the fix.<br> <br> =C2=A0 =C2=A0 This problem only affected Kerberized NFS mounts when the<br> =C2=A0 =C2=A0 "gssname" mount option was used.=C2=A0 Other Kerber= ized NFS<br> =C2=A0 =C2=A0 mount cases already used GSS_C_NO_NAME and work ok.<br> =C2=A0 =C2=A0 A workaround if you do not have this patch is to do a<br> =C2=A0 =C2=A0 "kinit -k host/FQDN" as root on the machine, follow= ed by<br> =C2=A0 =C2=A0 the Kerberized NFS mount without the "gssname" moun= t<br> =C2=A0 =C2=A0 option.<br><br></blockquote><div><br></div><div><br></div><di= v>Hi Rick,</div><div><br></div><div>This doesn't seem like a good long-= term fix.</div><div>If we're going to have a gssname argument, we shoul= d actually make</div><div>it take effect, rather than silently ignoring it,= which is what using GSS_C_NO_NAME</div><div>does (it indicates the use of = "any credential", which ends up meaning the</div><div>default cre= dential when used on a GSS initiator).</div><div><br></div><div>It should b= e possible to inspect the "junk" credential from gss_acquire_cred= ()</div><div>and learn more about what happened (perhaps a non-kerberos mec= hanismm was</div><div>picked, or the name was in the wrong format)=C2=A0 us= ing various gss_inquire_*() calls,</div><div>as a diagnostic measure.=C2=A0= Unfortunately I don't anticipate having a huge amount of time</div><di= v>to put into it anytime soon...</div><div><br></div><div>Thanks,</div><div= ><br></div><div>Ben</div></div></div> --000000000000c531cc05f1b71015--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ5_RoA0YQQ8R59M8nSkFaTz6T%2BjWMnyxZjGT4PZn-kn_SpzXQ>