Vendoring krb5?

[benesch]

Thanks very much for putting this together! Would you accept a PR that adds a vendored feature that builds GSSAPI from the krb5 sources?

[estokes]

I'll sure take a look at it, but I have some concerns. My reason for not doing it initially was that Kerberos is pretty deeply integrated into the OS and network environment. How would a user of that vendored library get a TGT, access cached tickets, etc? Are you proposing to install kinit and all the tools somewhere? Particularly worrying, if the system has one version of mit kerberos, and we download and build another, then are we playing with fire, are we going to corrupt ticket caches, crash, send wrong messages to the KDC, and generally create a huge nightmare for some poor sysadmin trying to debug an application?

Maybe my concerns are overblown. What application do you have in mind for a vendored library?

[benesch]

Agreed that dynamic linking seems like the easier option for most deployments, but we've had explicit customer requests over at @MaterializeInc to have SASL/GSSAPI/libkrb5 statically linked into our application. You'll have to be careful to get a compatible copy of kinit or whatever other command-line tools you need, but the on-disk formats are relatively stable that I don't think it'll be too much of an issue in practice.

FWIW, you can be at risk with dynamic linking too, since there's no guarantee that the build machine has the same version of krb5 as the target machine.

Anyway, I put together a krb5-src crate that handles building a vendored copy of libkrb5. I've hooked it up directly to sasl2-sys for now, but long term I'd love to instead link against this crate, and have it automatically toggle between static and dynamic linking at the user's option.

[estokes]

Ok, sure, that all makes perfect sense to me, I'd be very happy to accept such a PR.

[pimeys]

Hi. We're having a pull request using the crate in Tiberius for MSSQL Kerberos authentication. What is the current status of vendoring the krb5? I haven't really used Kerberos authentication anywhere, so what kind of a problem a mismatching client and server version would be? How many Kerberos versions are out there that do not work together, and is this still a problem in 2020?

I apologize for having so many questions, but I'm trying to understand the implications of us statically compiling Kerberos support in Prisma...

[estokes]

The status is, I have not worked on it. Not saying I won't, but as of yet have not found the time to do all the testing I would need to do in order to be comfortable putting my name on it. As for your questions, I pretty much share all of them, and any answer I can give is just my educated guess. I know of 2 open source Kerberos distributions, Heimdall, and MIT. On the network, of course they interoperate just fine, I in fact run a heimdal kdc and MIT on my clients without any issues. As for the ticket formats, locations, etc, I don't know, I guess some of it might be standardized, but I wouldn't bet it's as well tested as the network protocol.

Beyond the potential issues with ticket files, replay caches, etc, I struggle to see the use for a vendored library in this case. If the machine doesn't have a working Kerberos install, how are you going to get a tgt in the first place? How is the vendored library going to know how to contact the kdc, and if it does find it how will it prove the processes' identity? On the other hand, if the machine does have a working Kerberos setup, then why are we vendoring the library? I'm not against vendored libraries by any means, but Kerberos seems like a special case that's somewhere near vendoring libc. It's part of the operating system ...

[pimeys]

These are valid questions and I'll come back to these when we'll be deciding of our stance to support Kerberos on MSSQL with Prisma.

For now, our method of distribution is a compiled binary, which means the compiling machine (and all dev machines) must have a working Kerberos installation if enabling the feature on Tiberius. And the question then is, when we distribute this binary to our users, will it work in any other Kerberos system without weird issues? Not really looking for an answer to all of this, just writing out my concerns here until I really need to make my decision.

[estokes]

Well, I can answer that one if it helps. If you compile against MIT Kerberos and they run heimdal it won't work. Otherwise, it should dynamically link to the version they have installed, and it should work fine, gssapi has not changed in a very long time, so the interfaces will match even if the library versions are different.

[pimeys]

Meaning, our build matrix should include both: MIT and Heimdal... We already build against different SSL implementations and different operating systems, so this would definitely add to that. Let's see how much our users want this feature, but my guess is there is a real demand.

[estokes]

MIT is much much more common, Red hat Ubuntu, and Debian use it by default.

[abatkin]

A common use case for me (in production) is to volume-mount a Kerberos ticket cache from the host into a Docker container (along with a KRB5CCNAME environment variable pointing at the destination path). The container needs a working krb5.conf, but other than that, the ticket cache can be used "as is" without any of the supporting utilities (i.e. kinit, klist, etc...).