Re: Bogus-looking SSL code in postmaster wait loop - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Bogus-looking SSL code in postmaster wait loop
Date
Msg-id 28663.972488542@sss.pgh.pa.us
Whole thread Raw
In response to Bogus-looking SSL code in postmaster wait loop  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Magnus Hagander <mha@sollentuna.net> writes:
> SSL_pending() returns true when there is data in the SSL buffer of the
> socket.
> The problem is that since SSL uses block cipher, even if you read one just
> byte from the socket (using ssl_read), OpenSSL will read a complete block
> from the network, in order to be able to decrypt it. In this case, the rest
> of that block will sit in the (SSL *)-structure. If you then select() the
> socket, it will *not* return that there is more data available, because that
> data has already been read from the network layer. Therefor, the select()
> call would block *even though there is more data available* on that socket.

OK.  In that case the existing code is actually broken, because what
will happen as soon as SSL_pending returns true is that the select will
*never* complete.

> struct timeval tv;
> tv.tv_sec = 0;
> tv.tv_usec = 0;
> if (select(nSockets, &rmask, &wmask, (fd_set *) NULL,
>     no_select?&tv:(struct timeval *)NULL) < 0)

> That way, select() would block *only* if there is nothing on the sockets
> *and* nothing in the SSL buffers.

This looks reasonable to me, and should avoid the DOS issue.  We don't
want to skip the select() entirely, else we'd be ignoring our other
clients.

I'll put this in (with comments ;-)) unless there are objections from
the floor ...
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [GENERAL] A rare error
Next
From: Lamar Owen
Date:
Subject: Re: 7.0.x RPMs