[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