Re: Sane error messages for SSL retry cases

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Sane error messages for SSL retry cases
Date: 2006-10-02 23:07:37
Message-ID: 200610022307.k92N7cC16279@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


Is this a TODO? I don't see how it is a new problem, meaning it
probably is for 8.3.

---------------------------------------------------------------------------

Tom Lane wrote:
> As per a recent discussion in pgsql-admin,
> http://archives.postgresql.org/pgsql-admin/2006-09/msg00297.php
> libpq doesn't cope well with the situation where the server is
> configured to allow only SSL connections (or only non-SSL connections)
> and there is some unrelated-to-SSL connection problem such as wrong
> password. The reason is that libpq is set up to retry with the other
> kind of connection (either dropping or adding SSL) for just about any
> sort of error returned by the server. This may lead to reporting "no
> pg_hba.conf entry", or some such, rather than the more useful "password
> authentication failed".
>
> I am tempted to propose that libpq should only retry in the other mode
> when the server specifically returns "no pg_hba.conf entry", and not for
> other server errors (beyond the initial do-you-do-SSL-at-all handshake
> of course). This would save a useless fork() cycle on the server as
> well as make it more likely that we return a useful error message.
>
> There are some corner cases where this might fail to connect when
> a blind retry would have succeeded, but they all involve the server
> offering different auth methods depending on SSL or not --- an example
> is "hostssl + ident" and "hostnossl + password", and you fail the ident
> test but could have produced the correct password. ISTM that is a
> scenario where the user should use the "sslmode" parameter to control
> which method is tried first.
>
> One problem with implementing this proposal is that we currently use the
> generic INVALID_AUTHORIZATION_SPECIFICATION sqlstate for a bunch of
> distinct conditions including "no pg_hba.conf entry". Looking directly
> at the error string is of course not localization-proof, so we'd have to
> break down that errcode into some more-specific categories. Which is
> probably not a bad idea anyway, but it would mean that the nicer
> behavior would only happen when talking to an 8.2 or later server.
>
> Thoughts? Is this something to tackle during beta, or must we put it
> off till 8.3?
>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/docs/faq

--
Bruce Momjian bruce(at)momjian(dot)us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2006-10-02 23:25:48 Re: Faster StrNCpy
Previous Message Bruce Momjian 2006-10-02 23:01:46 Re: horo(r)logy test fail on solaris (again and