From: Magosanyi Arpad <mag@bunuel.tii.matav.hu>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Magosanyi Arpad <mag@bunuel.tii.matav.hu>
Cc: pgsql-hackers@postgresql.org
Cc: pgsql-interfaces@postgresql.org
Subject: Re: libpgtcl bug (and symptomatic treatment)
Date: Fri, 5 Jun 1998 07:37:34 +0100
Message-ID: <19980605083734.42625@bunuel> (raw)
In-Reply-To: <25908.896980012@sss.pgh.pa.us>
References: <199805291706.NAA22900@hub.org>
<25908.896980012@sss.pgh.pa.us>
[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'
problem.]
>
> 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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-interfaces@postgresql.org
Cc: mag@bunuel.tii.matav.hu, tgl@sss.pgh.pa.us, pgsql-hackers@postgresql.org
Subject: Re: libpgtcl bug (and symptomatic treatment)
In-Reply-To: <19980605083734.42625@bunuel>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox