Re: Warning about invalid .pgpass passwords

Tom Lane wrote:
> Bruce Momjian <bruce@momjian.us> writes:
> > The attached patch reports the fact that .pgpass was used if the libpq
> > connection fails:
> 
> The test is in a very inappropriate place --- it will be missed by
> several fully-supported code paths.

Agreed.  I moved it to the error return label ("error_return") in
PQconnectPoll(), and placed the code in a new function.

> > I am not sure if I like the parentheses or not.
> 
> I don't like 'em.  If you don't have enough confidence in the message to

OK, parentheses removed.

> be replacing the normal error string, you probably shouldn't be doing
> this at all.  We'll look silly if we attach such a comment to a message
> that indicates a network failure, for example; and cases where the
> comment is actively misleading would be even worse.
> 
> I'm inclined to think that maybe we should make the server return a
> distinct SQLSTATE for "bad password", and have libpq check for that
> rather than just assuming that the failure must be bad password.
> The main argument against this is probably that it would tell a bad
> guy that he's got a valid username but not a valid password.  Not
> sure if that's a serious issue or not --- I seem to recall that we
> are exposing validity of user names already (or was that database
> names?).  It would also mean that the new message only triggers when
> talking to a 9.0+ server, but since we've gotten along without it
> till now, that aspect doesn't bother me at all.

Modifying the backend to issue this hint seems like overkill, unless we
have some other use for it.

> A compromise would be to check for
> ERRCODE_INVALID_AUTHORIZATION_SPECIFICATION, which in combination
> with the knowledge that we got asked for a password would give
> fairly high confidence though not certainty that the problem is a bad
> password.

I originally considered using the SQLSTATE but found few uses of it in
the frontend code.  However, I agree it is the proper solution so I now
coded it that way, including a loop to convert from the 6-bit sqlstate
to base-10.  (FYI, the same C file hardcodes ERRCODE_APPNAME_UNKNOWN as
a string for historical reasons, but I didn't do that.)

Updated patch attached.

-- 
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  PG East:  http://www.enterprisedb.com/community/nav-pg-east-2010.do