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

* Andrew Klosterman (andrew5(at)ece(dot)cmu(dot)edu) wrote:
> On Tue, 14 Feb 2006, Stephen Frost wrote:
> <snip>
> > It's kind of a chicken-and-egg here because the backend decides what
> > authentication mechanism to ask for based off the username (at least in
> > part) through pg_hba.conf, so you can't find out the authentication
> > method until you know the username so all methods to find the username
> > have to be exhausted. You could avoid this by explicitly passing
> > 'user=' into the connection parameters though... Would be interesting
> > to know what happens then...
>
> When asking about "explicitly passing 'user=' in to the connection
> parameters" do you mean that the EXEC SQL CONNECT line that ecpg parses
> should specify a username?

Oh, I see now. You're not using PQconnectdb but rather PQsetdbLogin, or
at least, that's what ECPG is using. This ends up meaning that you
can't pass in your own conninfo string and during the PQsetdbLogin call,
libpq calls connectOptions1 with an empty conninfo string, which makes
libpq think there's no set username which in turn makes it ask the
Kerberos libraries for a username...

As an initial comment, it seems like it'd be a good thing to update ECPG
to use PQconnectdb. It's possible this is exposed already in some way
but I'm not familiar enough with ECPG to know.

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.
I'm a little worried about if that would work for all the various ways
to use libpq to connect to the database...

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

Thanks,

Stephen