Re: Please review: Authentication after fork

Peter Eisentraut <peter_e@gmx.net> writes:
>> Um, shouldn't collection of the startup packet be done after the fork?

> To handle query cancel requests we'd need to take a peek in the
> postmaster, unless we want to start up a new backend for that.

Why?  The PM child will inherit the list of active backends from the
parent, so it could still issue the kill(SIGINT) without any problem
that I can see.  You do have a point: we'll need to generate the
CancelKey for a child much earlier than now, ie, before the fork.
(Drat, a few more cycles in the top postmaster.)  But that doesn't
look like a big problem.  Doesn't really matter if we generate a
cancel key for a child that never becomes a backend.

> Also, I'm not sure how the SSL negotiation would work.

Moving SSL negotiation out of the top process is one of the key points
of this whole change.  AFAIK, SSL negotation is another place where the
postmaster currently blocks on a single client, and thus is a trivial
attack point for DOS attempts.

It's not immediately clear to me whether InitSSL() should be called once
by the top postmaster process or once in each child that sees it is
getting an SSL connection request.  But other than that, I don't see
an issue...

            regards, tom lane