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

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

patch attached. I tested it (runtime testing and "make check") on recent
darwin, freebsd, netbsd and ubuntus with and without gssapi enabled.  I
had to re-enable and change around some header checks to make things
work right under darwin.

This is definitely much more elegant than what I was originally proposing.

If this ends up being acceptable, it would be nice if it was also pulled
up to pg17 for the next point release (I also tested the patch against the
pg17 branch), but if not, hopefully it'll make it into pg18.

It looks like the right way to submit this is via an email to
pgsql-hackiers, but if I should do soemthing else, please let me know.

Thanks again,
-Todd
diff --git a/configure b/configure
index 93fddd69981..b4db627b399 100755
--- a/configure
+++ b/configure
@@ -12550,6 +12550,65 @@ fi

 if test "$with_gssapi" = yes ; then
   if test "$PORTNAME" != "win32"; then
+    { $as_echo "$as_me:${as_lineno-$LINENO}: checking for library containing gss_init_sec_context" >&5
+$as_echo_n "checking for library containing gss_init_sec_context... " >&6; }
+if ${ac_cv_search_gss_init_sec_context+:} false; then :
+  $as_echo_n "(cached) " >&6
+else
+  ac_func_search_save_LIBS=$LIBS
+cat confdefs.h - <<_ACEOF >conftest.$ac_ext
+/* end confdefs.h.  */
+
+/* Override any GCC internal prototype to avoid an error.
+   Use char because int might match the return type of a GCC
+   builtin and then its argument prototype would still apply.  */
+#ifdef __cplusplus
+extern "C"
+#endif
+char gss_init_sec_context ();
+int
+main ()
+{
+return gss_init_sec_context ();
+  ;
+  return 0;
+}
+_ACEOF
+for ac_lib in '' gssapi_krb5 gss 'gssapi -lkrb5 -lcrypto'; do
+  if test -z "$ac_lib"; then
+    ac_res="none required"
+  else
+    ac_res=-l$ac_lib
+    LIBS="-l$ac_lib  $ac_func_search_save_LIBS"
+  fi
+  if ac_fn_c_try_link "$LINENO"; then :
+  ac_cv_search_gss_init_sec_context=$ac_res
+fi
+rm -f core conftest.err conftest.$ac_objext \
+    conftest$ac_exeext
+  if ${ac_cv_search_gss_init_sec_context+:} false; then :
+  break
+fi
+done
+if ${ac_cv_search_gss_init_sec_context+:} false; then :
+
+else
+  ac_cv_search_gss_init_sec_context=no
+fi
+rm conftest.$ac_ext
+LIBS=$ac_func_search_save_LIBS
+fi
+{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_search_gss_init_sec_context" >&5
+$as_echo "$ac_cv_search_gss_init_sec_context" >&6; }
+ac_res=$ac_cv_search_gss_init_sec_context
+if test "$ac_res" != no; then :
+  test "$ac_res" = "none required" || LIBS="$ac_res $LIBS"
+
+else
+  as_fn_error $? "could not find function 'gss_init_sec_context' required for GSSAPI" "$LINENO" 5
+fi
+
+
     { $as_echo "$as_me:${as_lineno-$LINENO}: checking for library containing gss_store_cred_into" >&5
 $as_echo_n "checking for library containing gss_store_cred_into... " >&6; }
 if ${ac_cv_search_gss_store_cred_into+:} false; then :
@@ -12604,8 +12663,8 @@ ac_res=$ac_cv_search_gss_store_cred_into
 if test "$ac_res" != no; then :
   test "$ac_res" = "none required" || LIBS="$ac_res $LIBS"

-else
-  as_fn_error $? "could not find function 'gss_store_cred_into' required for GSSAPI" "$LINENO" 5
+$as_echo "#define HAVE_GSS_STORE_CRED_INTO 1" >>confdefs.h
+
 fi

   else
@@ -13806,8 +13865,6 @@ if test "x$ac_cv_header_gssapi_ext_h" = xyes; then :
 #define HAVE_GSSAPI_EXT_H 1
 _ACEOF

-else
-  as_fn_error $? "gssapi_ext.h header file is required for GSSAPI" "$LINENO" 5
 fi

 done
diff --git a/configure.ac b/configure.ac
index b6d02f5ecc7..79be5f8851b 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1337,8 +1337,9 @@ fi

 if test "$with_gssapi" = yes ; then
   if test "$PORTNAME" != "win32"; then
-    AC_SEARCH_LIBS(gss_store_cred_into, [gssapi_krb5 gss 'gssapi -lkrb5 -lcrypto'], [],
-                   [AC_MSG_ERROR([could not find function 'gss_store_cred_into' required for GSSAPI])])
+    AC_SEARCH_LIBS(gss_init_sec_context, [gssapi_krb5 gss 'gssapi -lkrb5 -lcrypto'], [], [AC_MSG_ERROR([could not find
function'gss_init_sec_context' required for GSSAPI])]) 
+
+    AC_SEARCH_LIBS(gss_store_cred_into, [gssapi_krb5 gss 'gssapi -lkrb5 -lcrypto'],
AC_DEFINE([HAVE_GSS_STORE_CRED_INTO],1, [Define to 1 to build with gss_store_cred_into support])) 
   else
     LIBS="$LIBS -lgssapi32"
   fi
@@ -1543,7 +1544,7 @@ if test "$with_gssapi" = yes ; then
   AC_CHECK_HEADERS(gssapi/gssapi.h, [],
     [AC_CHECK_HEADERS(gssapi.h, [], [AC_MSG_ERROR([gssapi.h header file is required for GSSAPI])])])
   AC_CHECK_HEADERS(gssapi/gssapi_ext.h, [],
-    [AC_CHECK_HEADERS(gssapi_ext.h, [], [AC_MSG_ERROR([gssapi_ext.h header file is required for GSSAPI])])])
+    [AC_CHECK_HEADERS(gssapi_ext.h, [], [])])
 fi

 PGAC_PATH_PROGS(OPENSSL, openssl)
diff --git a/src/backend/libpq/be-gssapi-common.c b/src/backend/libpq/be-gssapi-common.c
index 7adea3060e1..fd0ffc97fbf 100644
--- a/src/backend/libpq/be-gssapi-common.c
+++ b/src/backend/libpq/be-gssapi-common.c
@@ -107,6 +107,7 @@ pg_store_delegated_credential(gss_cred_id_t cred)
                 minor;
     gss_OID_set mech;
     gss_cred_usage_t usage;
+#ifdef HAVE_GSS_STORE_CRED_INTO
     gss_key_value_element_desc cc;
     gss_key_value_set_desc ccset;

@@ -132,6 +133,7 @@ pg_store_delegated_credential(gss_cred_id_t cred)
         pg_GSS_error("gss_store_cred", major, minor);
     }

+#endif
     /* Credential stored, so we can release our credential handle. */
     major = gss_release_cred(&minor, &cred);
     if (major != GSS_S_COMPLETE)
diff --git a/src/include/libpq/be-gssapi-common.h b/src/include/libpq/be-gssapi-common.h
index 72f05748b6d..36a58a1bb2e 100644
--- a/src/include/libpq/be-gssapi-common.h
+++ b/src/include/libpq/be-gssapi-common.h
@@ -18,11 +18,15 @@

 #if defined(HAVE_GSSAPI_H)
 #include <gssapi.h>
+#ifdef HAVE_GSSAPI_EXT_H
 #include <gssapi_ext.h>
+#endif
 #else
 #include <gssapi/gssapi.h>
+#ifdef HAVE_GSSAPI_GSSAPI_EXT_H
 #include <gssapi/gssapi_ext.h>
 #endif
+#endif

 extern void pg_GSS_error(const char *errmsg,
                          OM_uint32 maj_stat, OM_uint32 min_stat);
diff --git a/src/include/pg_config.h.in b/src/include/pg_config.h.in
index db6454090d2..a86cdae5094 100644
--- a/src/include/pg_config.h.in
+++ b/src/include/pg_config.h.in
@@ -48,6 +48,9 @@
 /* Define to build with GSSAPI support. (--with-gssapi) */
 #undef ENABLE_GSS

+/* Define if gss_store_cred_into is available */
+#undef HAVE_GSS_STORE_CRED_INTO
+
 /* Define to 1 if you want National Language Support. (--enable-nls) */
 #undef ENABLE_NLS

On Wed, Dec 06, 2023 at 10:57:15PM -0500, Tom Lane wrote:
> 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...

Heimdal in the master branch sure does; I'm the author if
gss_store_cred_into() and gss_store_cred_into2().  Idk when we'll do an
8.0 release though.  We've run out of steam.  The reality is that the
world needs PostgreSQL to support OAuth w/ JWT more than the world needs
Kerberos or Heimdal's implementation of it.

> ... 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 krb5 API is horrible.  Do not use it if you can avoid it.  The
GSS-API is better, mostly.

Nico
-- 

On Wed, Dec 06, 2023 at 06:54:22PM -0500, kovert@omniscient.com wrote:
> 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.

Apple switched because Apple hired then developers of Heimdal, and they
liked it better than MIT Kerberos.  I have worked on both and know them
intimately well and I too prefer Heimdal, mainly because it has a very
nice ASN.1 compiler.

Apple does enhance their fork of Heimdal, and they publish their changes
with Darwin drops.  But they do not contribute back to Heimdal.

> 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

Well, MIT and Heimdal support the KCM: cache type, which is an IPC
interface to the system credentials cache daemon, which is basically
what the API: cache type is, and they both support the CCAPI anyways,
which is also what the API: cache really is (basically it's a shared
object exporting an API for credentials caches).  So they can both use
the OS X API: cache.  Well, I think so -- I don't use OS X so I don't
know how well the OS X API: cache works with Heimdal or MIT Kerberos,
but I believe it should.

Nico
-- 

On Wed, Dec 06, 2023 at 10:57:15PM -0500, Tom Lane wrote:
> 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...

Ok I took a look as I was wondering why even bother calling
gss_store_cred_into() or any flavor of gss_store_cred*() in postgres.  I
see that you always store delegated credentials into a MEMORY: cache,
but... do you ever use the delegated credentials?  Yes, possibly through
postgres_fdw, as that uses libpq, and libpq is the only place that calls
gss_init_sec_context().

(Makes me wonder though how that's going to work with OAuth w/ JWT.
Perhaps postgres_fdw should use local credentials rather than those
delegated by the client, but then... which credentials?  That could be
configurable by database, I suppose.)

If, however, you kept the gss_cred_id_t deleg. cred. handle output by
gss_accept_sec_context() then you could use those outright and not need
to store the creds.

In other words: you may not need gss_store_cred_into().

Also, if you set KRB5CCNAME=MEMORY: _before_ storing the delegated
credentials then gss_store_cred() is good enough and you don't need
gss_store_cred_into() or gss_store_cred_into2().

ASIDE: To use delegated credentials means:

a) you would pass them (without having to "store" them) to
   gss_init_sec_context() to impersonate the initiator principal to some
   other service,

and/or

b) you would use gss_store_cred()/ gss_store_cred_into() /
   gss_store_cred_into2() to store the crendentials into a ccache of
   type FILE:, DIR:, API:, or KCM: and then spawn (fork/exec,
   posix_spawn()) a process that would use it, or send the name of that
   ccache to a process that would use it, where "use it" means to call
   gss_init_sec_context() using that ccache (or a credential handle
   acquired from that ccache with gss_acquire_cred_from()).

Since you're using a MEMORY: ccache we can safely assume that letting
another process access it is not the use-case for storing deleg. creds.,
as only fork() progeny that don't exec can access the same MEMORY:
ccache:

Nico
-- 

Nico Williams <nico@cryptonector.com> writes:
> On Wed, Dec 06, 2023 at 10:57:15PM -0500, Tom Lane wrote:
>> 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.

> Heimdal in the master branch sure does; I'm the author if
> gss_store_cred_into() and gss_store_cred_into2().  Idk when we'll do an
> 8.0 release though.  We've run out of steam.

Yeah, this is what makes me fearful about putting in changes to re-support
Heimdal.  It seems like it's more or less abandonware so far as the
upstream developers are concerned, which is not comforting with any
package, but especially not for security-critical code.  I understand
that downstream packagers such as Apple and the BSDen are trying to
fill the gap, but how much should their efforts be relied on?

We could certainly take the attitude suggested upthread that
"we'll allow you to build with Heimdal, and if it breaks you
get to keep both pieces".  But I dunno.  We get blamed when
users do obviously-stupid stuff like use a guessable superuser
password on a database they've exposed to the internet [eg, 1].
It would be a lot more obviously our fault if we say nothing
when a user chooses a known-insecure library to build against.

So I've still got really mixed emotions about this project.
I totally understand the desire to use these library versions,
but I can't help fearing that people will regret doing so ...
and then want to shift the blame to us.

            regards, tom lane

[1] https://www.aquasec.com/blog/pg_mem-a-malware-hidden-in-the-postgres-processes/

On Tue, Apr 08, 2025 at 02:18:40AM -0400, Tom Lane wrote:
> Nico Williams <nico@cryptonector.com> writes:
> > Heimdal in the master branch sure does; I'm the author if
> > gss_store_cred_into() and gss_store_cred_into2().  Idk when we'll do an
> > 8.0 release though.  We've run out of steam.
> 
> Yeah, this is what makes me fearful about putting in changes to re-support
> Heimdal.  It seems like it's more or less abandonware so far as the
> upstream developers are concerned, which is not comforting with any
> package, but especially not for security-critical code.  I understand

Right now heimdal/heimdal basically is abandonware, yes, but not
Apple's.  I wish it weren't so as I've had a great deal of fun working
on it over the past decade plus, but there's loads of other things to
work on.

> that downstream packagers such as Apple and the BSDen are trying to
> fill the gap, but how much should their efforts be relied on?
> 
> We could certainly take the attitude suggested upthread that
> "we'll allow you to build with Heimdal, and if it breaks you
> get to keep both pieces".  But I dunno.  We get blamed when
> users do obviously-stupid stuff like use a guessable superuser
> password on a database they've exposed to the internet [eg, 1].

It's the _GSS-API_.  It's pretty much a standard.  You're making use of
a non-standard extension (gss_store_cred_into()) that's not strictly
needed since you could just either a) keep the gss_cred_id_t value
output by gss_accept_sec_context() and use that if needed anywhere
(probably only postgres_fdw), or b) not accept delegated credentials.
(a) might require changes to the interface to extensions, idk.  But
anyways, if you were not using non-standard extensions then you wouldn't
need to care if the user wants to link postgres with Heimdal or MIT or
anything else.  Heck, there's a GSS wrapper around SSPI that can be used
on Windows even (though it's obscure).

gss_store_cred() is a standards-track RFC, though it turns out to not be
good enough, which is why gss_store_cred_into() and
gss_store_cred_into2() exist, but in this particular case (PG)
gss_store_cred() is in fact good enough (see other reply).

> It would be a lot more obviously our fault if we say nothing
> when a user chooses a known-insecure library to build against.

Sure.

> So I've still got really mixed emotions about this project.
> I totally understand the desire to use these library versions,
> but I can't help fearing that people will regret doing so ...
> and then want to shift the blame to us.

In this case OP wants to use _Apple_'s Heimdal so they can make sure
they're using Apple's API: ccache.  Apple presumably supports their
Heimdal fork even if the upstream is currently abandonware-ish.  I think
you should always allow the use of the OS's authn. infrastructure where
you have the code for it.

Nico
--