Re: Doing authentication in backend

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Doing authentication in backend
Дата
Msg-id 18522.992540546@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Doing authentication in backend  (Peter Eisentraut <peter_e@gmx.net>)
Ответы Re: Doing authentication in backend  (Peter Eisentraut <peter_e@gmx.net>)
Re: Doing authentication in backend  (ncm@zembu.com (Nathan Myers))
Список pgsql-hackers
Peter Eisentraut <peter_e@gmx.net> writes:
> If we did this the straightforward way (exchange authentication packets
> after fork()) then rogue clients could connect, start a backend, twiddle
> thumbs, never finish the authentication exchange, meanwhile having filled
> up the limit on the number of connections.

True, but don't fool yourself that a similar DOS attack is not possible
now.  The resource limit that an attacker can hit now is the maximum
number of open file descriptors for the single postmaster process, which
may be quite a lot lower than the maximum number of process table
entries, depending on how your system is configured.

Also note that we could easily fix things so that the max-number-of-
backends limit is not checked until we have passed the authentication
procedure.  A PM child that's still busy authenticating doesn't have
to count.


> ISTM that there is some merit in having authentication happen *before*
> doing much else, especially allocating per-connection resources.

Sure, which is why the postmaster is written the way it is.  But you
have to be willing to code the postmaster in a way that prevents it from
blocking on behalf of one client.  We don't have that now for IDENT,
we are about to not have it for PAM, and I don't see a lot of enthusiasm
out there for adhering to those coding rules with the rigidity needed to
realize the theoretical benefit.

Another problem with the present setup is total cost of servicing each
connection request.  We've seen several complaints about connection-
refused problems under heavy load, occurring because the single
postmaster process simply can't service the requests quickly enough to
keep its accept() queue from overflowing.

Forking the postmaster (without an exec) is a relatively cheap
operation, since the PM has only a small amount of writable data and
very few open files.  I believe forking before authenticating would
improve the accept-queue-overflow problem by reducing the amount of
work done before the PM can accept() another connection request.

Moreover, if we went over to fork-before-authenticate, we could rip out
all the poor man's multitasking code that's in the postmaster.  That
would make the PM simpler, more understandable, and ultimately more
reliable.

So on the whole I think changing would be a win.
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: What (not) to do in signal handlers
Следующее
От: Tom Lane
Дата:
Сообщение: Re: What (not) to do in signal handlers