Re: Error-like LOG when connecting with SSL for password authentication

From: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
To: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
Cc: PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Error-like LOG when connecting with SSL for password authentication
Date: 2017-07-03 12:02:11
Message-ID: 431eb445-82b7-25bf-54ee-52b7e889326a@iki.fi
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 05/24/2017 05:29 PM, Michael Paquier wrote:
> Attached is an updated patch.

Thanks, I've pushed the backend read part of this patch. That's enough
to fix the original complaint with password authentication. I think the
rest was a bit dubious, and I'm hesitant to commit that (or at least to
backport):

* Backend write: you wouldn't really expect a client to disconnect,
while the backend is trying to send something to it. You'll get an error
in the non-SSL case too, although I guess the error message would be
different.

* Frontend read: pqReadData has this, after calling pqsecure_read:

> /*
> * A return value of 0 could mean just that no data is now available, or
> * it could mean EOF --- that is, the server has closed the connection.
> * Since we have the socket in nonblock mode, the only way to tell the
> * difference is to see if select() is saying that the file is ready.
> * Grumble. Fortunately, we don't expect this path to be taken much,
> * since in normal practice we should not be trying to read data unless
> * the file selected for reading already.
> *
> * In SSL mode it's even worse: SSL_read() could say WANT_READ and then
> * data could arrive before we make the pqReadReady() test, but the second
> * SSL_read() could still say WANT_READ because the data received was not
> * a complete SSL record. So we must play dumb and assume there is more
> * data, relying on the SSL layer to detect true EOF.
> */
>
> #ifdef USE_SSL
> if (conn->ssl_in_use)
> return 0;
> #endif

* Frontend write: Same as in the backend, I think having the server
disconnect while you're trying to send to it is not expected. Not sure
if the error message is here again different, but seems best to just
leave it alone.

- Heikki

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Marina Polyakova 2017-07-03 12:07:11 Re: WIP Patch: Pgbench Serialization and deadlock errors
Previous Message Ashutosh Sharma 2017-07-03 11:44:34 Re: hash index on unlogged tables doesn't behave as expected