Ron Chmara wrote:
>>> Do the "persistent-connected" Postgres backends ever timeout or die?
>> No. A backend will sit patiently for the client to send it another
>> query or close the connection.
>This does have an unfortunate denial-of-service implication, where
>an attack can effectively suck up all available backends, and there's
>no throttle, no timeout, no way of automatically dropping these....
Well, if you are talking about an environment where you don't trust
your users and they can badly effect each other then you almost
certainly don't want to be using persistant connections with PHP/Apache.
You are probably running multiple databases/logins which would make
it inefficient anyway.
>However, the more likely possibility is similar to the problem that
>we see in PHP's persistant connections.... a normally benign connection
>is inactive, and yet it isn't dropped. If you have two of these created
>every day, and you only have 16 backends, after 8 days you have a
lockout.
To some extent, this could be combatted with the Apache
MaxRequestsPerChild directive. But in reality I don't see the
problem here. Persistant connections do exactly what the name
suggests. If you don't trust your application logic to be right,
or don't trust your users, then don't use (or allow use) of
persistant connections.
I don't think it'd be too hard to come up with DOS attacks featuring
PHP (or any other language for that matter).
===dos.php===
while (true)
{
set_time_limit(20);
fopen('http://servername/dos.php','r');
}
=============
This is why you have Terms Of Service, contracts and the like :)
--
Paul McGarry mailto:paulm@opentec.com.au
Systems Integrator http://www.opentec.com.au
Opentec Pty Ltd http://www.iebusiness.com.au
6 Lyon Park Road Phone: (02) 9878 1744
North Ryde NSW 2113 Fax: (02) 9878 1755