On Apr 24, 2007, at 12:25 PM, <israel.garcia@xxxxxxxxxxxx> wrote:
Hi again, I was reading from the net
http://www.kriptopolis.org/node/4067 about a forkbomb and ran it
from a
root console in a non-critical machine running CentOS4.4 and the
serevr
goes down... the command I ran was :(){ :|:& };:
Please, does anyone knows how to aboid this on CentOS?
Easy: don't forkbomb your own system as root.
First, understand that it didn't "go down". The system was working as
designed. There's a limit to the number of processes that can be
running, and you exhausted it. No new processes could start, so you
couldn't log in again, or even use any functionality not built into
the shell (ps, etc). Besides that, the load was quite high from many
processes trying to fork as fast as they possibly could (even though
all those fork() calls were failing with EAGAIN), so the system was
slow.
Since you were sitting at the shell that caused the problem, you
could have hit ctrl-Z to suspend the first forkbomb subshell, then
"kill -9 0" (a bash builtin) to kill the entire process group, and it
would recover. Likewise if you happened to know the pid of the
process group leader, "kill -9 -PID" would work. Or if you have a
root shell running with a lot of builtin utilities (like BusyBox),
you could use those to find the offending process group. Otherwise,
you're screwed.
It's possible to prevent unprivileged users from hogging all of the
system resources (processes running, RAM, whatever) through the
ulimit facility. But Linux (unlike other Unix systems) does not honor
root's process limit. [1] Even if it did apply, hitting that
artificially lower limit would still mean you couldn't fork() as
root, so killing root processes would still be tricky - probably
impossible without setup work.
So basically, you can prevent unprivileged users from doing this but
not root. That matches the Unix philosophy - root's supposed to know
what he's doing:
"UNIX was not designed to stop its users from doing stupid things, as
that would also stop them from doing clever things." – Doug Gwyn
Cheers,
Scott
[1] - <http://groups.google.com/group/mlist.linux.kernel/
browse_thread/thread/f771d3d01478babb>. More precisely, it's
controlled by capability bits. In general, root has those bits set
and other users don't.
--
Scott Lamb <http://www.slamb.org/>
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
