Re: BUG #16041: Error shows up both in pgAdmin and in Ruby (pg gem) - Segmentation fault

Greetings,

* Chris Bandy (chris(dot)bandy(at)crunchydata(dot)com) wrote:
> On 12/3/19 5:31 PM, Stephen Frost wrote:
> >* Chris Bandy (chris(dot)bandy(at)crunchydata(dot)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.

No, I don't think it's got anything to do with that ... or largely to do
with PG, except that libpq with v12 now uses more of the GSSAPI library
than it used to.

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

I wouldn't be at all surprised if there's other bugs lurking in the old
version of Heimdal that Apple hacked up and distributes with their base
OS.

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

Perception isn't reality though and upgrading to a new major version of
libpq is going to pretty regularly involves new library calls or calls
being made in ways they weren't before. If that exposes a bug in
that library (particularly one that's been fixed in more recent versions
of the library), that's not on us to hack around or attempt to solve,
imv. Perhaps someone else has a differing opinion and wants to try and
figure out a way to solve this that doesn't materially make things worse
for users that are running with a modern library, which would be great,
but I can't get too worked up about it.

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

Great, that sounds like it's probably the right approach to addressing
this.

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

I wouldn't be against doing something here but I don't have a Mac myself
and I don't plan to spend time trying to hack around their broken
library. I'm also not entirely convinced that we should just throw an
error if we come across this busted library- psql doesn't fork and
hasn't got any problems, so it seems a bit overkill to just refuse to
work with the MacOS library.

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

I'm.. not terribly impressed by that blog's arguments around fork(),
particularly since it seems to be claiming things that are actually not
true about fork but which are true about threads. In fact, what it
seems to really be getting at is that running with threads and fork'ing
at the same time is awful complicated to get right, and that's pretty
accurate, but that doesn't make just using fork() an issue.

That blog post aside, it looks like what it's getting at is that you
can't link to MacOS libraries and also fork() and expect things to be
sane, and while that's unfortuante, that isn't really our issue to go
figure out how to fix or address.

Thanks,

Stephen