Re: Possible PostgreSQL 8.3beta4 bug with MD5 authentication in psql?

Mark Cave-Ayland <mark(dot)cave-ayland(at)ilande(dot)co(dot)uk> writes:
> I'd say that you definitely don't want a user password prompt if libpq's
> password is wrong, since I can see this would break a lot of scripts
> that weren't launched directly from the shell

Agreed, we don't want the behavior to suddenly turn interactive when
the user expected it not to be.

> As for the second point, I'm not too worried about how many times you
> are asked for the password - I personally am happy with the one attempt
> as it stands at the moment.

On reflection, this ought to be an application decision anyway; libpq
isn't going to be a good place to do it since it can have no memory
of how many times the "same" connection was tried.

Also, on further reflection I realize that PQconnectionUsedPassword
is broken for dblink's usage too! It's currently defined, in essence,
as "the connection used a password-based auth method". But that fails
to distinguish where it got the password from. In particular, as of
CVS HEAD it's still possible for a non-superuser to impersonate
postgres on a dblink connection, if the DBA has taken the
not-unreasonable step of setting up a ~/.pgpass in postgres' home
directory.

Fortunately, existing release branches don't use that technique,
or we'd have a live security problem here. But anyway, this seemingly
trivial patch has turned out to be pretty snake-bit :-(

So what I think we must do is split the function into two:

PQconnectionNeedsPassword: true if server demanded a password and there
was none to send (hence, can only be true for a failed connection)

PQconnectionUsedPassword: true if server demanded a password and it
was supplied from the connection function's argument list, *not*
from environment or a password file.

Offhand it looks like only dblink needs the second version ---
all of our client-side code wants the first one.

Barring objections I'll go code this up ...

regards, tom lane