Re: BUG #19411: libpq 16.x exhibits a memory leak when connections are repeatedly created and destroyed

On Fri, Oct 30, 2026 at 12:32 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> > The current code
> > always requests delegation if conn->gssdelegation is true (so if
> > pg_GSS_get_cred_cache()/gss_acquire_cred() fail, then delegation will
> > still be attempted with GSS_C_NO_CREDENTIAL). The new code requests
> > delegation only if gss_acquire_cred() succeeds -- if that fails but
> > the later GSS_C_NO_CREDENTIAL attempt succeeds for some weird
> > GSS-specific reason, shouldn't we still try to delegate as directed?
>
> How can delegation succeed if there's nothing to delegate?

IIUC, GSS_C_NO_CREDENTIAL doesn't actually mean "no credentials" to
gss_init_sec_context(), it means "get the default credentials from
somewhere magic." I don't know enough about the API to know whether
the gss_acquire_cred() call we're making separately is equivalent to
that magic behavior.

> Also,
> the equivalent stanza in pqsecure_open_gss (fe-secure-gssapi.c,
> lines 641-656 in master) behaves this way. I'm much more prepared
> to believe that pqsecure_open_gss's behavior is intentional; for
> one thing because it matches its comments, which pg_GSS_continue
> didn't.

Hmm, okay.

> > Are there any delegation cases where we were actually expecting to
> > overwrite the previous, valid, credentials?
>
> Doubt it. There is nothing different about what a repeat call
> to pg_GSS_get_cred_cache will do, so I'd expect it to fetch
> credentials that are exactly like the old ones, modulo perhaps
> a slightly newer expiration time.

I was worried about cases like pg_store_delegated_credential(), where
we manipulate the default creds in memory. But if we never do anything
like that in between client calls to pg_GSS_get_cred_cache(), then
it's probably not a concern.

> I tried running the src/test/kerberos
> tests with --enable-coverage, and found that they reach every call
> of pg_GSS_get_cred_cache *except* the one in pqsecure_open_gss ---
> but that's because we already have credentials there, as evidenced by
> the fact that the "gss_flags |= GSS_C_DELEG_FLAG" line is reached.
> So we do seem to need pg_GSS_continue's call.

Huh. I'll try to take a closer look when I can.

> In any case, it does not seem to make sense
> to be passing different parameters to successive calls of
> gss_init_sec_context.

Agreed [1]:

The initiator should not change any of the input
parameters to GSS_Init_sec_context() between calls to it during the
loop, with the exception of the input_token parameter, which will
contain a message from the acceptor after the initial call, and the
input_context_handle, which must be the result returned in the
output_context_handle of the previous call to GSS_Init_sec_context()
(GSS_C_NO_CONTEXT for the first call). RFC 2743 only
requires that the claimant_cred_handle argument remain constant over
all calls in the loop, but the other non-excepted arguments should
also remain fixed for reliable operation.

Thanks,
--Jacob

[1] https://www.rfc-editor.org/info/rfc7546/#section-3