In message <CAM5tNy6R2tXOLA_0YhBXzt7iDYXtmTxJfReEkazeNivrGTHw9w@mail.gmail.c om> , Rick Macklem writes: > On Mon, Jul 28, 2025 at 1:20=E2=80=AFAM Konstantin Belousov <kostikbel@gmai= > l.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 Sun, Jul 27, 2025 at 08:26:03PM -0700, Rick Macklem wrote: > > > On Tue, Jul 22, 2025 at 9:00=E2=80=AFAM Cy Schubert <Cy.Schubert@cschub= > ert.com> wrote: > > > > > > > > CAUTION: This email originated from outside of the University of Guel= > ph. 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= > e...@uoguelph.ca. > > > > > > > > In message <ah98inxobigu3...@kib.kiev.ua>, Konstantin Belousov writes= > : > > > > > On Mon, Jul 21, 2025 at 07:46:45AM -0700, Cy Schubert wrote: > > > > > > In message <47c3cc37-6f32-4376-900a-b5387b981...@freebsd.org>, Je= > ssica > > > > > > Clarke w > > > > > > rites: > > > > > > > On 21 Jul 2025, at 15:10, Cy Schubert <c...@freebsd.org> wrote: > > > > > > > >=3D20 > > > > > > > > The branch main has been updated by cy: > > > > > > > >=3D20 > > > > > > > > URL: =3D > > > > > > > https://cgit.FreeBSD.org/src/commit/?id=3D3Dc7da9fb90b0b6385e99= > bb7747476359 > > > > > b=3D > > > > > > > 712993fa > > > > > > > >=3D20 > > > > > > > > commit c7da9fb90b0b6385e99bb7747476359b712993fa > > > > > > > > Author: Cy Schubert <c...@freebsd.org> > > > > > > > > AuthorDate: 2025-07-19 14:11:18 +0000 > > > > > > > > Commit: Cy Schubert <c...@freebsd.org> > > > > > > > > CommitDate: 2025-07-21 14:07:22 +0000 > > > > > > > >=3D20 > > > > > > > > KRB5: Enable MIT KRB5 by default > > > > > > > >=3D20 > > > > > > > > Set WITH_MITKRB5=3D3Dyes as the default. > > > > > > > >=3D20 > > > > > > > > Rebuild all USES=3D3Dgssapi ports is recommended. > > > > > > > >=3D20 > > > > > > > > A clean buildworld is required. > > > > > > > > > > > > > > That=3DE2=3D80=3D99s going to be quite annoying and cause a lot= > of issues =3D > > > > > > > given > > > > > > > WITH_CLEAN is now the default. Can we do something in depend-cl= > eanup.sh > > > > > > > to delete everything from the obj tree that needs to be rebuilt= > if we > > > > > > > detect the wrong kerberos implementation was previously built? > > > > > > > > > > > > All binaries that depend on any kerberos libraries must be rebuil= > t. > > > > > > WITHOUT_CLEAN will fail at various spots. Meta mode should take c= > are of > > > > > > this for us. > > > > > Does the statement mean that ABI for the base libraries was broken? > > > > > If yes, and the new libs have the same name as the old, we must bum= > p > > > > > dso versions. > > > > > > > > Three new libs have the same names. Most don't. The three with the sa= > me > > > > names are libkrb5, libgssapi_krb5 and libcom_err. > > > > > > > > libgssapi_krb5 is a merge of the Heimdal libgssapi_* files. For examp= > le, > > > > there is no libgssapi_spnego in MIT. > > > > > > > > The libcom_err contains the same but updated MIT functions. > > > > > > > > libkrb5 removes Heimdal-only functions. > > > > > > > > There is no libasn1 nor libroken in MIT. > > > > > > > > The differences are outlined at https://k5wiki.kerberos.org/wiki/Samb= > a%27s_u > > > > se_of_Heimdal_symbols,_with_MIT_differences. > > > I know diddly about how libraries are handled, but is it possible to pu= > t the > > > old Heimdal 1.5.2 libraries somewhere (semi-private) under different na= > mes? > > > > > > I ask because it is going to be very difficult to port the gssd to the > > > new libraries. > > > > > > The problem is that the KGSSAPI code assumes some stuff very specific > > > to Heimdal. Take a look at sys/kgssapi/krb5/krb5_mech.c and you'll see > > > what I mean. (There's code that parses the keys etc out of the internal= > ly > > > generated tokens. I have no idea where to even find the information on > > > how/where the MIT code hides this stuff and it a large part of krb5_mec= > h.c > > > looks like it will have to be re-written to work with the MIT libraries= > .) > > > > It might be better to extract the required bits and keep just them. > > Perhaps even moving that bits from vendor to FreeBSD-owned code area. > > > > I do not think that keeping large pieces of code in vendor without update= > s > > is a good plan. > I will work on it. I just cannot guarantee timing. > > The next step to getting the gssd to work with MIT is finding the MIT > structure that gss_ctx_id_t refers to. If that structure isn't a lot > different than the Heimdal one, the conversion shouldn't be too bad. > (I'll start on that to-day.) > > I understand that this does need to be upgraded. > It is unfortunate that the KGSSAPI code is wired specifically for > Heimdal. (Another approach would be to add a new upcall to the > gssd daemon to extract the keys and then, hopefully, a kerberos > library call could be used instead of having a "home rolled" > chunk of code in the kernel that has to be updated whenever > the structure returned by the library call changes.)
I agree. We should isolate the kerberos data structures from the kernel as much as possible to allow us to quickly pivot to a new Kerberos, whether it be MIT, Heimdal or something else. I notice Linux uses the GSSAPI proxy. I'll bring that into ports. I don't know whether we need that here or not -- probably not. And adding an additional daemon between the KDC and the kernel isn't my preference ATM. > > I didn't realize this existed until yesterday when I bumped > into it while debugging the kerberized NFS mount. I didn't think the the contexts were that different. > > If you glance at krb5_import() in sys/kgssapi/krb5/krb5_mech.c, > you'll see how messy this could get. gssd should share its own data structure with the kernel rather. This externalizes any mapping or conversion of the context into one that provides the kernel a static interface (as much as possible). -- Cheers, Cy Schubert <cy.schub...@cschubert.com> FreeBSD UNIX: <c...@freebsd.org> Web: https://FreeBSD.org NTP: <c...@nwtime.org> Web: https://nwtime.org e**(i*pi)+1=0 > > rick
