Re: BUG #2246: Bad malloc interactions: ecpg, openssl

* Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
> Stephen Frost <sfrost(at)snowman(dot)net> writes:
> > Another approach would be to have PQsetdbLogin build up a conninfo
> > string and pass that into connectOptions1 instead of calling
> > connectOptions1 with an empty string and then changing the values
> > afterwards. That'd probably be too large of a change to get in as a
> > bugfix though. An alternative might be to move the pg_fe_getauthname()
> > call to connectOptions2 as it's actually a bit more work than one might
> > expect and if that can be avoided then that's probably all to the good.
>
> Right offhand I like the idea of pushing it into connectOptions2 --- can
> you experiment with that? Seems like there is no reason to call
> Kerberos if the user supplies the name to connect as.

Sure thing, I'll take a look at this probably tommorow night or thursday
evening.

> > Sorry I don't have a simple answer. :/ In the end it seems like the
> > Kerberos libraries should be able to survive Kerberos not being
> > configured or whatever is going on to make it try to malloc 0-bytes...
>
> We may be spending too much time on this one point --- as long as
> Kerberos isn't *writing* into the zero-length alloc, there is nothing
> illegal immoral or fattening about malloc(0). Can you get ElectricFence
> to not abort right here but continue on to the real problem?

Good point.

Stephen