Skip site navigation (1) Skip section navigation (2)

Re: libpgtcl bug (and symptomatic treatment)

From: Magosanyi Arpad <mag(at)bunuel(dot)tii(dot)matav(dot)hu>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Magosanyi Arpad <mag(at)bunuel(dot)tii(dot)matav(dot)hu>, pgsql-hackers(at)postgresql(dot)org, pgsql-interfaces(at)postgresql(dot)org
Subject: Re: libpgtcl bug (and symptomatic treatment)
Date: 1998-06-05 06:37:34
Message-ID: 19980605083734.42625@bunuel (view raw, whole thread or download thread mbox)
Lists: pgsql-hackerspgsql-interfaces
[please cc: to me the answer, as I am not on the mailinglist (yet?)]

A levelezőm azt hiszi, hogy Tom Lane a következőeket írta:
> But the real reason I'm writing this message is the comment about PQreset
> possibly failing.  I know of one case in which PQreset will not work:
> if the database requires a password then PQreset will fail.  (Why, you
> ask?  Because connectDB() in fe-connect.c deliberately erases the
> password after the first successful connection.)  Is this the situation
> you are running into, Magosanyi?  Or is there another problem in there?
> It seems to me that the password issue should only result in a failed
> reconnection, not a coredump.  Where exactly is the segfault occurring?

Exactly, the connection had a password. I can't tell you exactly where the
core dump occurred, but surely it was inside PQreset.

> I have been intending to propose that connectDB's deletion of the
> password be removed.  The security gain is marginal, if not completely
> illusory.  (If a bad guy has access to the client's address space,
> whether he can find the password is the least of your worries.  Besides,
> where did the password come from?  There are probably other copies of
> it outside libpq's purview.)  So I don't think it's worth breaking
> PQreset for.

And anyway the password goes out plaintext on the net (okay, it can go
crypt()ed, but the crypted version is also enough to connect to your postgres 
account, should someone snooping on the net).
As setting up kerberos is a PITA, especially for us in the free world 
(in cryptoexportlaw sense), is it possible to hack in some other light yet
unsnoopable authentication method? (SRP comes to mind) Also, the encryption
of the connections would be a nifty thing.
[I am aware of the following facts: (1) there is kerberos also in the free 
world, (2) with ssh port forwarding I can work around the 'plain on the net'

> Alternatively, we could eliminate PQreset entirely.  It doesn't really
> do anything that the client application can't do for itself (just close
> and re-open the connection; two lines instead of one) and its presence
> seems to encourage the use of poorly-considered error "recovery"
> schemes...

I guess it would break compatibility. Maybe a two-step method would be 
worth considering: first insert a warning (to stderr), that PQreset is
considered harmful. After some time remove it.
Maybe it is not worth to do the second step.

GNU GPL: csak tiszta forrásból

In response to

pgsql-hackers by date

Next:From: Oleg BroytmannDate: 1998-06-05 06:39:39
Subject: Re: [PATCHES] Postgres-6.3.2 locale patch
Previous:From: David GouldDate: 1998-06-05 05:40:53
Subject: Re: [HACKERS] Re: [PATCHES] Postgres-6.3.2 locale patch (fwd)

pgsql-interfaces by date

Next:From: Jose' Soares Da SilvaDate: 1998-06-05 14:35:28
Subject: Re: [INTERFACES] PgAccess running on Win95 ?
Previous:From: Ken WrightDate: 1998-06-05 00:30:34
Subject: odbcexpress

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group