Re: BUG #13741: vacuumdb does not accept valid password

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com>, brown(at)fastmail(dot)com, "pgsql-bugs(at)postgresql(dot)org" <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: BUG #13741: vacuumdb does not accept valid password
Date: 2015-11-12 19:41:03
Message-ID: 15139.1447357263@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-hackers

Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> writes:
> Fujii Masao wrote:
>> ISTM that the attached simpler patch can fix the problem.
>> But maybe I'm missing something...

> Hmm, this is a very good and simple idea that looks like it should do
> the trick. I would just add a comment explaining why we're using a
> static.

NAK. This changes the behavior of connectDatabase() for *all* users
of that function, not only vacuumdb. But the proposed behavioral
change is only appropriate for calling programs in which only a single
host/port/database target is used per execution. In other contexts,
reusing the prior password is not just inappropriate but could actually
create security issues. (It's possible that this behavior would be okay
for all existing callers, but that doesn't mean we should put in a
security gotcha for future uses.)

We could make this approach work if connectDatabase() remembered all
the parameters internally, and only tried to reuse the password when
they all match. Or maybe it'd be better to alter the API so the caller
can say whether to try to reuse a saved password or not. But I'm not sure
whether either of those answers is cleaner than the previous patch.

(BTW, I notice that pg_dumpall.c has a version of connectDatabase in
which the "static" trick is already being used, sans any documentation.
That's okay for pg_dumpall, but might be an issue if anyone copies-and-
pastes that version somewhere else ... and in any case it's fair to ask
why that version hasn't been merged with common.c.)

regards, tom lane

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message manu 2015-11-12 19:57:35 BUG #13774: upgrade from 9.1 to 9.4 'succeeds' without enough disk space
Previous Message John R Pierce 2015-11-12 19:04:17 Re: connect to C

Browse pgsql-hackers by date

  From Date Subject
Next Message David G. Johnston 2015-11-12 19:52:12 Re: psql: add \pset true/false
Previous Message Daniel Verite 2015-11-12 19:38:49 Re: psql: add \pset true/false