, 2005-03-16
It's a sad day when an ancient fork bomb attack can still take down most of the latest Linux distributions.
Expand all |
Post comment
silly article
2005-03-17
Anonymous (4 replies)
Anonymous (4 replies)
silly article
2005-03-18
Anonymous (1 replies)
Anonymous (1 replies)
Linux Kernel Security, Again
2005-03-17
Anonymous (3 replies)
Anonymous (3 replies)
Linux Kernel Security, Again
2005-03-17
Jason V. Miller (Author) (3 replies)
Jason V. Miller (Author) (3 replies)
Linux Kernel Security, Again
2005-03-17
mrsad (1 replies)
mrsad (1 replies)
Linux Kernel Security, Again
2005-03-17
Jason V. Miller (Author) (1 replies)
Jason V. Miller (Author) (1 replies)
Linux Kernel Security, Again
2005-03-18
Anonymous (2 replies)
Anonymous (2 replies)
simple fork bomb?
2005-03-17
Anonymous (1 replies)
Anonymous (1 replies)
simple fork bomb?
2005-03-17
Jason V. Miller (Author) (3 replies)
Jason V. Miller (Author) (3 replies)
simple fork bomb?
2005-03-17
Anonymous (1 replies)
Anonymous (1 replies)
simple fork bomb?
2005-03-17
Jason V. Miller (Author) (1 replies)
Jason V. Miller (Author) (1 replies)
Intended use dictates the limits
2005-03-17
Erik Keller (1 replies)
Erik Keller (1 replies)
Intended use dictates the limits
2005-03-17
Jason V. Miller (Author) (4 replies)
Jason V. Miller (Author) (4 replies)
Linux Kernel Security, Again
2005-03-17
Anonymous (2 replies)
Anonymous (2 replies)
Linux Kernel Security, Again
2005-03-18
Anonymous (1 replies)
Anonymous (1 replies)
Linux Kernel Security, Again
2005-03-18
Gentoo User (1 replies)
Gentoo User (1 replies)
Linux Kernel Security, Again
2005-03-18
Another Gentoo User (2 replies)
Another Gentoo User (2 replies)
Debian IS vulnerable!
2005-03-18
Anonymous (2 replies)
Anonymous (2 replies)
Linux only? perhaps across the board problem? Conflict of interest?
2005-03-18
glotfeltys@gmail.com (1 replies)
glotfeltys@gmail.com (1 replies)
Jason's opinion is too biased
2005-03-18
Anonymous (2 replies)
Anonymous (2 replies)
Take the first step author.
2005-03-18
EG (2 replies)
EG (2 replies)

If you're running a heavily loaded Web server, you should increase the default limits (assuming that they are reasonably set) to handle the load that is acceptable for your machine.
"Is it the job of the distro maintainers to make a judgment on what the user's system can handle?"
No, but I do think that it's their job to prevent the default configuration from allowing any local user to take down the entire system.
"Default process, memory use, and other limits can be set to target what your "typical" modern computer can handle, but your old 486 may still buckle under the load before the limits are reached."
And understandably so. The limits have to be reasonable, however. The Mandrake machine was a Pentium 4 with a gigabyte of RAM. The OpenBSD machine, on the other end of the spectrum, was a Pentium 90 with 32MB of RAM. And yet a regular user still couldn't take down the OpenBSD machine.
"You either have to train users to tweak the limits for their environment, or to set them in the first place."
I agree. For this reason, limits should be set to something safe from the get-go. Just like allowing the user to install the machine with an empty root password, you're letting people who don't know better to show themselves in the foot far too easily.
"You don't want to antagonize the bulk of your customers by creating restrictions that may cause them problems."
If I was running a hosting provider, I think that my customers would be more upset if a single customer could take down a server handling 200 users, than if they had to make a special request in order to get their process limits increased - besides, this would even alert you to the problem that the customer requiring increased limits might not fare well on the machine they've been assigned to.
[ reply ]
Link to this comment: http://www.securityfocus.com/comments/columns/308/30973#30973