Weblog entry #4 for orchid
See all weblog entries made by orchid.
I do know now how fork bombs work but was suprised to see one in action on my (ubuntu breezy) laptop:
#include #include
int main(void)
{
while(1) {
fork();
}
return 0;
}
orchid@supergrass fork $ killall -9 a.out
bash: fork: Resource temporarily unavailable
orchid@supergrass fork $ screen -x
bash: fork: Resource temporarily unavailable
orchid@supergrass fork $ top
bash: fork: Resource temporarily unavailable
Now I realize during normal use its unlikely that you will accidently do this but
I could have just as easily been logged into a friends machine, whatever and been
compliling and testing little programs and suddenly I crash the machine.
It just seems like an unsafe default to have. Solaris I am told is 29995, I don't know what the other linux distro's set ulimit to, nor the BSD's for that matter, but hopefully its not "unlimited"
PS, how do you properly input code and or blockquotes etc etc in these blogs? I think ive messed it up a bit.
Comments on this Entry
[ Send Message | View Steve's Scratchpad | View Weblogs ]
You mostly did good on the code editting - just use <pre> - the only thing you have to remember is to escape the '<' characters as entities (e.g. & lt;).
(Looks like you had a long line in your code sample which is causing the wrapping there)
Regarding fork bombs I remember recently reading that Debian was one of the only recent distributions to be safe from them!
Steve
--
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
Anonymous is correct in observing that out-of-box Debian's /etc/security/limits.conf doesn't prevent fork bombs, nor using up all available disk space, and etc.. Here are the settings from my laptop, adjust to your needs...
I borrowed these from the settings for penguinppc.org which are really stringent, in my opinion. Actually though I've only been using a modification of Ethan's limits.conf for 30 minutes or so. ;) For now I wasn't sure what a good limit for stack, heap, etc.. was for my user so I added:
# /etc/security/limits.conf # [snip] #* soft cpu 1051200 #* hard cpu 1051200 * soft nproc 60 * hard nproc 80 #* soft core 1000000 #* hard core 1500000 * soft core 0 * hard core 0 * soft data 102400 * hard data 122880 * soft nofile 150 * hard nofile 200 * soft stack 8192 * hard stack 16384 * soft rss 46080 * hard rss 51200 * soft memlock 5120 * hard memlock 8192 * soft as 51200 * hard as 71680 * hard maxlogins 30 # Flush the rules for my own user core - # Setup the limits for my own user ################################################ # - core - limits the core file size (KB) ################################################ core soft core 0 core hard core 16384 # enable the core file for debugging # [snip]
I did more reading on the subject this morning and I haven't yet found anyone who's written a document that puts the descriptions into practical terms. For example how does one determine the amount of stack space that is sufficient for all desktop and development usage? And so on and so forth. I'm almost tempted to write a cross-platform tool to configure this... before I do so I'm curious if there's already GUI/curses PAM wizard for configuring limits?
Anyways so I did test the fork bomb and I was very pleased to see that my XMMS didn't skip a beat. I jumped to a root owned vt and it was snappy and responsive. I ran ps -afx and mused at the interesting tree of forks. Now if I can just figure out how to limit my user's memory usage slighlty below unlimited. So far I've determined that "data" affects X's ability to mmap the framebuffer device. Not sure how much it needs though.... stay tuned.
peace, metta,
core
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]