Message-ID: <19980605083734.42625@bunuel>
Date: Fri, 5 Jun 1998 07:37:34 +0100
From: Magosanyi Arpad <mag@bunuel.tii.matav.hu>
To: Tom Lane <tgl@sss.pgh.pa.us>
CC: Magosanyi Arpad <mag@bunuel.tii.matav.hu>, pgsql-hackers@postgresql.org,
	pgsql-interfaces@postgresql.org
Subject: Re: libpgtcl bug (and symptomatic treatment)
References: <199805291706.NAA22900@hub.org> <25908.896980012@sss.pgh.pa.us>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-2
Content-Transfer-Encoding: quoted-printable
In-Reply-To: <25908.896980012@sss.pgh.pa.us>; from Tom Lane on Thu, Jun 04,
	1998 at 06:06:52PM +0100

[please cc: to me the answer, as I am not on the mailinglist (yet?)]

A levelez=F5m azt hiszi, hogy Tom Lane a k=F6vetkez=F5eket =EDrta:
>=20
> 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.

>=20
> 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 postgr=
es=20
account, should someone snooping on the net).
As setting up kerberos is a PITA, especially for us in the free world=20
(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=
=20
world, (2) with ssh port forwarding I can work around the 'plain on the net'
problem.]

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

--=20
GNU GPL: csak tiszta forr=E1sb=F3l