Thread: Sane error messages for SSL retry cases
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
On Tue, Sep 26, 2006 at 02:18:59PM -0400, Tom Lane wrote: > 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? It sounds to me like a very nice idea that has to wait for the next cycle. Just getting agreement on the categories will take time and cycles, no? A -- Andrew Sullivan | ajs@crankycanuck.ca When my information changes, I alter my conclusions. What do you do sir? --attr. John Maynard Keynes
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@momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Bruce Momjian <bruce@momjian.us> writes:
> Is this a TODO? I don't see how it is a new problem, meaning it
> probably is for 8.3.
It's definitely not a new problem, but we hadn't recognized it before,
so it qualifies as a new bug. The question at hand was whether anyone
was excited enough about it to try to push a fix in for 8.2. Seems like
nobody is, so let's just put it on TODO:
* Fix libpq SSL retry to avoid useless repeat connection attempts and ensuing misleading error messages
regards, tom lane
Tom Lane wrote: > Bruce Momjian <bruce@momjian.us> writes: > > Is this a TODO? I don't see how it is a new problem, meaning it > > probably is for 8.3. > > It's definitely not a new problem, but we hadn't recognized it before, > so it qualifies as a new bug. The question at hand was whether anyone > was excited enough about it to try to push a fix in for 8.2. Seems like > nobody is, so let's just put it on TODO: > > * Fix libpq SSL retry to avoid useless repeat connection attempts and ensuing > misleading error messages Thanks, added. -- Bruce Momjian bruce@momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +