Re: [HACKERS] Doing authentication in backend
On Thu, Jun 14, 2001 at 01:42:26PM -0400, Tom Lane wrote: > 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. And impose a very short timeout on authentication. > 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. This last could also be addressed (along with Solaris's Unix Sockets problem!) by changing the second argument to listen(2) from the current SOMAXCONN -- which is 5 in Solaris 2.7 -- to 127. See the six-page discussion in Stevens UNPv1 beginning at page 93. This is not to say we shouldn't fork before authentication, for the above and other reasons, but the fix to listen(2)'s argument should happen anyway. Nathan Myers [EMAIL PROTECTED] ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Doing authentication in backend
Peter Eisentraut <[EMAIL PROTECTED]> 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 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Doing authentication in backend
Peter Eisentraut <[EMAIL PROTECTED]> writes: > Tom Lane writes: >> 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. > How does the postmaster know? And if the postmaster does get to know, > what does it do with children it has "accidentally" allowed in excess? The postmaster doesn't have to know, nor should it be in the business of enforcing the MaxBackends limit. It should just spawn off children (though maybe we should put a limit on total children, somewhat higher than MaxBackends, as a crude form of preventing runaway resource usage under a DOS attack). A spawned child will first proceed with the authorization cycle; if it fails, it just exits. If it succeeds, it will then try to become a backend. When it tries to insert an entry into the PROC array, if there's not an available slot then you lose (send "too many clients" failure message to client, and exit). We might have to reorganize the code a little bit so that this exit happens cleanly before anything else is done to shared memory, but it's surely doable. The PM itself has no real need to distinguish children that are active backends from those that are still doing authentication, AFAICS. regards, tom lane ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Doing authentication in backend
[EMAIL PROTECTED] (Nathan Myers) writes: > On Thu, Jun 14, 2001 at 01:42:26PM -0400, Tom Lane wrote: >> 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. > And impose a very short timeout on authentication. Yes. There's no time limit at present, but it will be easy to add one after we change to fork-before-authenticate (since each PM child can have its own itimer). > This last could also be addressed (along with Solaris's Unix Sockets > problem!) by changing the second argument to listen(2) from the current > SOMAXCONN -- which is 5 in Solaris 2.7 -- to 127. See the six-page > discussion in Stevens UNPv1 beginning at page 93. Unfortunately I only have Stevens' first edition, and it doesn't seem to have any such advice in it. Why is it a good idea to ignore the platform's specification of SOMAXCONN? Seems like on non-broken platforms, that would do more harm than good. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl