Re: pg16 && GSSAPI && Heimdal/Macos - Mailing list pgsql-hackers

 > "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