Thread: pg16 && GSSAPI && Heimdal/Macos

Earlier this year, there was a thread about GSSAPI for delegated
credentials and various operating systems ultimately that Heimdal had
atrophied enough that you were comfortable not supporting it anymore as
a GSSAPI library.

Thread:
https://www.postgresql.org/message-id/flat/ZDFTailRZzyGdbXl%40tamriel.snowman.net#7b4b7354bc3ea060fb26d51565f0ad67

In https://www.postgresql.org/message-id/3598083.1680976022%40sss.pgh.pa.us,
Tom Lane said:

 > I share your feeling that we could probably blow off Apple's built-in
 > GSSAPI.  MacPorts offers both Heimdal and kerberos5, and I imagine
 > Homebrew has at least one of them, so Mac people could easily get
 > hold of newer implementations.

I wanted to follow up on the decision to blow off Apple's built-in
GSSAPI.  Years back, for reasons I never found, Apple switched from MIT
to Heimdal and have been maintaining their own version of it.  I'm not
clear how well they maintain it but they have enhanced it.

One of the things that Apple put it in was a different centralized
credentials cache system. (named of the form "API:uuid").  This isn't
in Heimdal nor is it in MIT, so typical kerberos tickets issued by the
Apple provide Kerberos libraries are not accessible via other kerberos
versions provided by homebrew/macports/etc. (netbsd pkgsrc on macos can
be told to use the system libraries, which is what I do).  Installing a
parallel version makes the client experience awful since it means having
to manage two sets of tickets and ticket caches, and which one gets used
varies depending on what libraries they were linked against.

As you may have surmised, I use a mac as a client and use gssapi pretty
heavily to interact with numerous postgresql databases.  This has stopped
me from upgrading my client side to 16.  I'm wondering if there's be any
willingness to reconsider heimdal support under some circumstances?

thanks,
-Todd

kovert@omniscient.com writes:
> Earlier this year, there was a thread about GSSAPI for delegated
> credentials and various operating systems ultimately that Heimdal had
> atrophied enough that you were comfortable not supporting it anymore as
> a GSSAPI library.

Yup.

> As you may have surmised, I use a mac as a client and use gssapi pretty
> heavily to interact with numerous postgresql databases.  This has stopped
> me from upgrading my client side to 16.  I'm wondering if there's be any
> willingness to reconsider heimdal support under some circumstances?

The immediate reason for dropping that support is that Heimdal doesn't
have gss_store_cred_into(), without which we can't support delegated
credentials.  AFAICT, Apple's version doesn't have that either.
We could argue about how important that feature is and whether it'd be
okay to have an Apple-only build option to not have it.  However...

... there's another good reason to shy away from relying on Apple's
library, which is that they've conspicuously marked all the standard
Kerberos functions as deprecated.  It's not clear if that means
they're planning to remove them outright, but surely it's an indicator
that Apple doesn't want outside code calling them.

The deprecation notices that you get if you try to build anyway say
"use GSS.framework".  So if somebody wanted to try to support this in
a somewhat future-proof way, the thing to do would be to look into how
invasive it'd be to do it like that.  That's not something I plan to
put any effort into, but if you're desperate enough for this, maybe
you could push that forward.

            regards, tom lane

I spent some quality time with this and wanted to revisit.  It still
applies for pg17 and master of git (I was mucking about with master in
git).

 > > As you may have surmised, I use a mac as a client and use gssapi pretty
 > > heavily to interact with numerous postgresql databases.  This has stopped
 > > me from upgrading my client side to 16.  I'm wondering if there's be any
 > > willingness to reconsider Heimdal support under some circumstances?
 >
 > The immediate reason for dropping that support is that Heimdal doesn't
 > have gss_store_cred_into(), without which we can't support delegated
 > credentials.  AFAICT, Apple's version doesn't have that either.
 > We could argue about how important that feature is and whether it'd be
 > okay to have an Apple-only build option to not have it.  However...
 >
 > ... there's another good reason to shy away from relying on Apple's
 > library, which is that they've conspicuously marked all the standard
 > Kerberos functions as deprecated.  It's not clear if that means
 > they're planning to remove them outright, but surely it's an indicator
 > that Apple doesn't want outside code calling them.
 >
 > The deprecation notices that you get if you try to build anyway say
 > "use GSS.framework".  So if somebody wanted to try to support this in
 > a somewhat future-proof way, the thing to do would be to look into how
 > invasive it'd be to do it like that.  That's not something I plan to
 > put any effort into, but if you're desperate enough for this, maybe
 > you could push that forward.

I looked into this more, and the libpq frontend parts build and work just
fine with Heimdal (at least on mac), but the _server side_ requires a
more modern Kerberos to make gss_store_cred_into work.  I was basically
able to change setup a with_gssapi_client and ENABLS_GSS_CLIENT defines
in libpq and get it to build (I hacked it by hand to prove it out).
gss_store_cred_into is only called in the backend.

A pragma in code to ignore the apple deprecation notices and build
anyway.  They use GSSAPI extensively internally, so there's not a lot of
danger of that going away but on the chance that Apple go through with
actually removing the standard interface, it's a matter of using similar
calls in the framework. (or someone may build a shim).

I have the same general issue with OS's such as FreeBSD where I _really_
don't want to build a whole second Kerberos library just to make the
client work.  Server side, that's fine.

To that end, I'd like to propose a --with-gssapi-client-only type option
that's mutually exclusive with --with-gssapi that will trigger gssapi
linkage in just libpq but not in the backend. --with-gssapi would just
turn on the same flag that --with-gssapi-client-only uses.

In the future, if it stops building on the mac, then I'd probably end up
figuring out how to deal with migrating to the framework and kick back a
patch that would work with --with-gssapi-client-only.

My question is that if I submit a patch that does this, is there a
reasonable chance it would be accepted into the main branch.  If not,
I'll just maintain something (probably less hardened) patch privately --
it's not a difficult thing to do cleanly, but I'd rather not.  Obviously
you can't guarantee this until you see it, but I don't to bother if
there's no appetite.  I'd test it on what I have available (macos,
FreeBSD, NetBSD, ubuntu).

thanks,
-Todd

"Todd M. Kover" <kovert@omniscient.com> writes:
> To that end, I'd like to propose a --with-gssapi-client-only type option
> that's mutually exclusive with --with-gssapi that will trigger gssapi
> linkage in just libpq but not in the backend. --with-gssapi would just
> turn on the same flag that --with-gssapi-client-only uses.

I don't see how that's a good idea.  Notably, a system built that
way could not test its own GSS support.

Looking at the code a bit closer, I see that we will never try to
call gss_store_cred_into() unless the gss_accept_delegation GUC
is on --- which it is not by default.  So that certainly blows a
large hole in the idea that this is something we have to have.
I think that a more-probably-acceptable patch would be to set up
the code so that we can build without gss_store_cred_into() and
what the user sees is gss_accept_delegation can't be turned on.

I remain doubtful that this is a good idea from a big-picture
standpoint, though.  What this amounts to is un-desupporting
the Heimdal Kerberos libraries, which is a big deal from a
testing standpoint if nothing else.  Plus we'd be encouraging
people to depend on security-critical software that is, if
not effectively dead, at best in back-burner maintenance mode.

Is there a good reason why you can't build your Mac PG code
with MIT Kerberos from Homebrew or MacPorts?

            regards, tom lane

 > "Todd M. Kover" <kovert@omniscient.com> writes:
 > > To that end, I'd like to propose a --with-gssapi-client-only type option
 > > that's mutually exclusive with --with-gssapi that will trigger gssapi
 > > linkage in just libpq but not in the backend. --with-gssapi would just
 > > turn on the same flag that --with-gssapi-client-only uses.
 >
 > I don't see how that's a good idea.  Notably, a system built that
 > way could not test its own GSS support.

If you consider it from the admin/end user/etc perspective, it's a good
idea.  However, it's certainly a fair point that it can't be tested in a
vaccuum and automated testing of would be a ton harder.

 > Looking at the code a bit closer, I see that we will never try to
 > call gss_store_cred_into() unless the gss_accept_delegation GUC
 > is on --- which it is not by default.  So that certainly blows a
 > large hole in the idea that this is something we have to have.
 > I think that a more-probably-acceptable patch would be to set up
 > the code so that we can build without gss_store_cred_into() and
 > what the user sees is gss_accept_delegation can't be turned on.

If you think you'd take that, that's fine with me.  My very personal
use case is that on a laptop, I run a local postgres server that I
only connect to locally for local development and testing but from the
same machine, I connect to production systems that require Kerberos
authentication, so having a client that supports different things than
the server is just fine.  I'm basically stuck on pg15 to keep the
workflow, and my primary environment just upgraded to pg17.  (I used to
be ahead...)

 > I remain doubtful that this is a good idea from a big-picture
 > standpoint, though.  What this amounts to is un-desupporting
 > the Heimdal Kerberos libraries, which is a big deal from a
 > testing standpoint if nothing else.  Plus we'd be encouraging
 > people to depend on security-critical software that is, if
 > not effectively dead, at best in back-burner maintenance mode.

From a big picture standpoint, *BSD, macos, etc ship Heimdal as their
base OS Kerberos implementation, for whatever their reasons so they're
on the hook for security implications of that choice and you're just
letting people rely on the OS vendors choice.

So, I'm not sure sure you'd be encouraging it, but you'd certainly be
enabling it.

 > Is there a good reason why you can't build your Mac PG code
 > with MIT Kerberos from Homebrew or MacPorts?

Yeah, I had details in my original post, last year and is the main
reason I'm asking for this.  Basically - macos provides a system
wide in-memory credentials cache.  If I link against a different
library, that's lost.  I end up with two credentials caches, two
versions of kinit, tools on the same box that don't work the same.
Two credentials caches is also a support nightmare for people who
don't really understand what goes on under the hood and use the linked
software.

Personally, I'd also use this on FreeBSD and NetBSD clients if it was
available.  No point in having competing implementations in case there
are other on-system incompatibilites.  Linux ships with MIT, so it's
moot.

I actually do install postgresql from NetBSD pkgsrc, which is
macports/brew-like on my mac, but that has support for using the native
kerberos libraries; I've just broken it out into the most simple case
for this discussion.  If I build MIT Kerberos in that, the split brain
nature of two-credentials cache acutally gets worse (half of the things
I do use one cache beacause pkgsrc system-wide is linked against MIT,
the other half, like browsers or any binaryish things use the systemwide
one).  It becomes something that "just works" to something I need to
always be conscious of.

It's not likely that I'm the only person in the world running into that
(well, I know another person, so there's at least two :-). Breaking
out client support is a clean enough patch that it's not a big deal to
maintain it on my own, but in the spirit of collaboration, I was trying to
share.  To that end, I see three choices that will help me:

1) the client-only option described

2) some option that makes the code path for gss_store_cred_into optional
(what would you want to call it?)

3) implement everything _but_ the configure option for #1 (basically
means splitting out ENABLE_GSS and ENABLE_GSS_CLIENT) so that someone
with a little bit of knowledge could make minimal changes to the source
code in two places between configure and build and get this to work.
This does add complication to the base code, which is less than ideal,
of course.

I'm happy to pull together a patch for whatever y'all are willing to
work with me to integrate.  If nothing/none of the above, I'll just
patch code to make #3 and do the build/configure step.

In the nothing case, I'll also submit the same patch to both FreeBSD
ports and NetBSD pkgsrc to optionally allow the behavior; no idea
if they'll take it.  The last time I checked GSSAPI integration with
postgresql was just outright broken in FreeBSD ports, but that was with
pg16 and a while back; I dealt with it locally, but was waiting until I
sorted this out before submitting a patch to them.

thanks for considering this,
-Todd

"Todd M. Kover" <kovert@omniscient.com> writes:
> 2) some option that makes the code path for gss_store_cred_into optional
> (what would you want to call it?)

If we do this, I see no need to call it anything.  Just make configure
probe for whether the selected GSS library has gss_store_cred_into.

The other options you mention seem strictly worse from a documentation
and testing standpoint, and all of them open the question of exactly
how much we care to rely on Heimdal.  I take your point that if a
particular platform has an insecure version of Heimdal, it's their
problem not ours.  However, my recollection from the discussion a
couple years back is that different platforms offer significantly
different Heimdal releases, and making our code work with all of
those would be our problem.  (That consideration is why I'm so
allergic to the client-side-support-only proposal.  It is NOT okay
if we can't test it.)

            regards, tom lane