Messages in this thread | | | Date | Fri, 27 Dec 1996 22:13:48 GMT | From | Paul Flinders <> | Subject | Re: NT vulnerable to attack on CPU |
| |
Andi Gutmans writes: > > put a cronjob to run a bomb and this won't have any effect. ie. linux > limits (and prolly most unicees) are useless. I'm prolly going to hack the > kernel a bit to do the following: certain limit for uid's < 1000 and certain > limit for uid's > 1000 (users)
It would probably be better to add this feature to cron.
In fact I'm not sure that you even need to distinguish "system" from "user" for cron - even system cron jobs will probably have small memory footprints and small numbers of children so you could just set limits in the rc script which starts cron - eg change the line which starts cron so that it reads something like
/bin/bash -c "ulimit -u 10; exec crond"
that will run a shell (so the limits only apply to the cron daemon), set the max no of user processes and then start cron with that limit. As long as "the right thing" happens as cron switches UIDs (i.e cron ends up being limited to 10 processes per UID and not 10 total in the above example)
This seems to be a prime example of a case where the kernel already provides the mechanism adequately and it's up to the system administrator to define a policy which uses it - should he believe that he has a user community which requires these sorts of limits to be set.
Regards
Paul.
| |