Re: Bogus-looking SSL code in postmaster wait loop

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Magnus Hagander <mha(at)sollentuna(dot)net>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Bogus-looking SSL code in postmaster wait loop
Date: 2000-10-25 15:42:22
Message-ID: 28663.972488542@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Magnus Hagander <mha(at)sollentuna(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2000-10-25 15:50:45 Re: Re: [INTERFACES] RE: JDBC now needs updates for lar ge objects
Previous Message Lamar Owen 2000-10-25 15:33:28 Re: 7.0.x RPMs