Stephen Frost <sfrost@snowman.net> writes:
> * Tom Lane (tgl@sss.pgh.pa.us) wrote:
>> In the meantime, I did spot a code path that would explain the symptoms:
>> pqsecure_open_gss() clears allow_ssl_try sooner than it oughta. If
>> gss_wrap_size_limit() failed for some reason, we'd abandon the GSS
>> connection and try another one, and we would *not* try to SSL-ify
>> the new one.
> There are certainly some very odd GSSAPI implementations out there
> (including hacked up things particularly on Macs that we've seen..),
> though I've not run into one where I've seen that call fail.
The OP said he's on RHEL 8.3, so it ought to be mostly-stock Kerberos.
I've just been digging through the SRPM to see if they'd done anything
odd for FIPS mode or the like, and I'm not really finding anything.
> If it did fail though, surely the error messages would make that
> clear, and we're not seeing that here..?
No, because we won't report the failure from gss_wrap_size_limit;
we just discard that connection and try again.
> I'm not sure how, but it sure seems like somehow, in this case, we're
> going through the GSSAPI encryption code because we find GSSAPI
> credentials (entirely possible, even if you're not using them for
> talking to PG), the server responds with a "I haven't got support for
> that" in some fashion, and we're skipping SSL at that point. How that's
> happening isn't clear to me though, but the idea that it's because
> gss_wrap_size_limit() is failing seems very unlikely.
I already spent most of the day on theories like that, without any
success. I agree that this theory seems quite unlikely, but you
remember what Sherlock Holmes said.
regards, tom lane