On 12/3/19 5:31 PM, Stephen Frost wrote:
> Greetings,
>
> * Chris Bandy (chris.bandy@crunchydata.com) wrote:
>> Notice that host must be a TCP address (not Unix) and gssencmode must be
>> "prefer" (default is "prefer".) The version of the server doesn't appear to
>> matter; I tested 10, 11, and 12.
>
> So, gssencmode didn't exist in 10 or 11- but are you actually testing
> those different versions of *libpq*?
No, the libpq version in my tests is always 12. I was trying to say that
it doesn't appear to be an issue with the protocol/negotiation of GSS
encryption.
That does make me wonder, though, if/how the _server_ built by `brew
install postgresql` might be impacted by the macOS GSSAPI? All my tests
targeted a linux server.
>> This has been reported in a variety of Ruby projects and often dismissed as
>> "a PostgreSQL issue."
>
> I'm really inclined to say that this isn't a PG issue...
I agree, but at the same time the perception seems to be that
using/connecting to PostgreSQL crashes one's application. I think the
very reasonable default of gssencmode=prefer is partly responsible.
Users don't realize that by upgrading libpq they are opting in to new
security code paths (and library compatibility issues.)
> Unfortunately, MacOS is pretty well known to be terrible about less
> commonly used libraries and maintaining them. I'd suggest building a
> current version of the Kerberos libraries, making sure you're linking
> against just those and not whatever is provided by MacOS, and see if you
> still have an issue.
Investigating this has been the deepest exposure I've had to this...
yes, "unfortunate" reality.
Homebrew provides a recent version of krb5 (1.17 at this time) so I set
out to use it. A small diff to the formula proved successful. I'll
submit a patch to Homebrew linking back to this thread.
Is there anything that can/should be done on PostgreSQL's end now that
we know about this situation? The most I can imagine is to issue a
warning when macOS's GSSAPI is detected during build/configure. I don't
know how to do the latter and won't be surprised if the answer to the
former is "no."
> The other possibility is that this is an current bug in Heimdal, which
> seems to be the Kerberos library being used on MacOS, in which case
> you'd need to bring up the issue with them.
I'm out of my depth on this front. My impression from the traces is that
the incompatibility is in macOS keychain, and I'm willing to leave it at
that. While researching this topic, I found multiple cases where fork()
and the "dispatch queue" are incompatible.[1]
> There seems to be some indepedent confirmation of this being an issue
> with the Heimdal provided by MacOS:
>
> https://github.com/zenchild/gssapi/issues/12
I don't see any C level backtrace information in that thread, so I can't
tell if its the same issue.
Thank you for your help!
Chris
[1]: https://www.evanjones.ca/fork-is-dangerous.html