[Hcoop-discuss] CGI/PHP script security

[Ryan M.]

On Sat, 17 Dec 2005 08:34:47 -0500 (EST), NN wrote about "Re: [Hcoop-discuss] CGI/PHP script security" :

> So nicing doesn't solve the problem here.  Any large limit on runtime for
> scripts makes it simple for someone to starve out apache, and the larger
> the limit, the more likely this is to happen accidentally.  (Increasing
> the maximum number of Apache processes is not a solution either, because
> beyond some point processes start swapping out and this effectively causes
> DoS as well.)


Nicing is bad, anyhow, as it doesn't prevent the CPU from being hosed.

It'd be best if we had a kernel with a scheduler that allows processes to be SCHED_BATCH:

"Batch scheduling allows tasks to only use cpu time if the cpu is idle, rather than a proportion of cpu usage that "nice" does." 

The staircase scheduler included with the CK patch set provides this functionality, and it is set through "schedtool."  However, it is only currently maintained for the 2.6 kernel tree.  It is very mature. http://members.optusnet.com.au/ckolivas/kernel/   

In practice, the obvious use would be for certain cron jobs like updatedb, back-up, sa-learn, etc.  One could even use "toolsched" script to make gcc and other compilers _always_ run as SCHED_BATCH.  I think that the practical use of that goes without saying.  The goal is to have responsive server functions to the outside world, with user processes carefully moderated (but not restrictively so) to prevent any denial of service.

On the other side, the CK patch also includes SCHED_ISO.  It tries to ensure processes always get the CPU time they deserve -- it can be compared to real-time, but it will _never_ starve any process of CPU time (sshd would be good to set sched_iso, because then the likelyhood of sshd failing to respond due to an out of control process is deminished somewhat), and one doesn't have to be priviledged to access it.

I wish that 2.6.x wasn't condemned from our server.

My 2 won, 

Ryan