(Oh, and incidentally : Since 1966 there have been 9 World Cups and 10 European Championships [giving 19 major championships] and a total of 20 Grand Slams).
But "Hooray, we've won something besides a football tournament" does seem to imply that winning football tournaments is something of a habit for the British, when it pretty clearly isn't.
Yeah, we finally won something which is not a football tounrament
When was the last time you won a football tournament? Everyone was saying how many years ago Wales's last Grand Slam was, but it was 12 years *after* England last won a soccer tournament.
Well, sure that might happen. But in the grand scheme of "things people are likely to do by accident", I'm more worried about them unplugging the machine in order to vaccuum up the biscuit crumbs under the desk...
then to have your machine vulnerable to being completely taken down trivially,
There is nothing trivial about obtaining a user account on my machine. If someone you don't trust can run a forkbomb on your machine, you've already been Pwned, and it's too late to apply a band aid.
What makes you think any given distro wouldn't set _reasonable_ default limits?
Because what's "reasonable" varies from person to person, machine to machine and usage patterns.
How many processes do you really need?
I've no idea. The trouble is, you've no idea how many processes I need, either. And neither do Bill Gates, Linus Torvalds, Bruce Perens, the Debian process-ulimit-policy-discuss mailing list, the Grinch or Eric Bakke. That makes it pretty hard to set a "sane" limit that works for everyone
How much memory?
All of it, and sometimes a little bit more.
I mean, what would you rather have: a machine that's vulnerable by default to resource exhaustion, or a machine that's _not_ vulnerable by default.
If only it were that simple. If I'm running a Linux mail-server on a 386/66 with 8MB RAM then its not going to take a lot of processes to down the box. However, if I'm running a busy web server on a Dual Xeon box, then Apache is going to want to spawn more processes than would kill my mail server...
So, if you protect my box from resource exhaustion with a defaulty hard limit, one of two things will happen.
i) If the limit is low, my web server won't function very well, as it won't be allowed to spawn processes. ii) If the limit is high, y mail server could be killed by a fork bomb before the limits get hit.
Simply put, you're treating process limits as a panacea, when it isn't.
In REALITY (is that different from reality in some way?) it's impossible to define a sane cap. What's sane for you, might be completely unusable for me, or vice versa.
Sorry, but the ability of a mail reader to automagically run as many programs as it likes is a feature, not a bug.
Mail readers take data from untrusted sources. That's why they need extra care from a security perspective.
Shells don't take data from an untrusted source, unless you don't trust your users. As I've said many times here, if you don't trust your users, then you need to set limits for them. If you do trust your users, then you don't.
You should not allow unprivilged users to fork as many processes as they want.
You should not allow untrusted users to fork as many processes as they want. However, very few boxes have untrusted users. If yours does, the command you need is ulimit
but there should be "some" way for the system to differentiate between useful processes spawning tasks to achieve a computational goal, vs an abhorrent process run amuck.
Yes, they're should. But, sadly, that problem is one that is generally considered hard by computer scientists. I didn't follow it closely, but the debates around the heuristics for the Linux kernel out-of-memory process killer tells me that it really isn't easy to do.
Maybe I'm just biased, because last year, I had a horrible time overcoming some hard-coded limits (on stack size) when trying to run some Fortran code on a SunOS box.
You look at the reasonable defaults, and decide to change them on a per user basis for the different users
But isn't that exactly what you have to do now? Set limits by hand on a per-process basis?
Your sensible defaults (which you're still loathe to define) haven't help our server admin. They do prevent a fork bomb, but they might well also stop me from running my own user-space code, if it doesn't meet the expectations of a distro-writer who I've never met.
But if the system becomes unusable, surely it is a bug.
I run codes *all the time* that cause my system to become completely unresponsive. By running huge numerical simulations without enough physical RAM. I'd be mightily annoyed if the kernel told me I wasn't allowed to do this.
Users use resources. If an admin wants to starve their untrustworthy users of resources, they can (and, if they've a lot of untrustworthy users, its highly recommended), but there is simply no compelling reason why it should be turned on by default.
I love Linux but the hypocrocy is a bit much. Its OK to admit it was bad or admit MS's settings were OK, but you cannot do both.
There's no hypocrisy, at least not from me. I've never criticised MS software because local users are able to fill up disk space, spawn a zillion processes, suck the processor and generally exhaust the resources... That's what users do, they use up your resources.
But given that distribution/kernel vendors do not have the first idea of i) My hardware ii) How many users I want iii) What programs / services will be running,
how in the name of crikey are they supposed to determine what a "Reasonable limit" would be?
Sorry but the ability for a non-privileged user to run as many programs as the like is a feature, not a bug. Inability to turn that feature off would be a bug, but given that few modern Linux boxes are actually used as multi-user remote-login accounts, it's a completely unecessary overhead.
And if you are administrating a true multi-user old-style-Unix type server, you should know enough to stop people fork bombing you (i.e. quotas).
Slashdot Mirror
But someone's going to win a major soccer title every two years whether or not they're objectively any good.
Check out the Greeks in Euro 2004.
(Oh, and incidentally : Since 1966 there have been 9 World Cups and 10 European Championships [giving 19 major championships] and a total of 20 Grand Slams).
Oh, I agree with you on every word of that.
But "Hooray, we've won something besides a football tournament" does seem to imply that winning football tournaments is something of a habit for the British, when it pretty clearly isn't.
Not any more, because Marvel is getting creamed in the City Of Heroes Lawsuit.
Well, sure that might happen. But in the grand scheme of "things people are likely to do by accident", I'm more worried about them unplugging the machine in order to vaccuum up the biscuit crumbs under the desk...
So, if you protect my box from resource exhaustion with a defaulty hard limit, one of two things will happen.
i) If the limit is low, my web server won't function very well, as it won't be allowed to spawn processes.
ii) If the limit is high, y mail server could be killed by a fork bomb before the limits get hit.
Simply put, you're treating process limits as a panacea, when it isn't.
Shells don't take data from an untrusted source, unless you don't trust your users. As I've said many times here, if you don't trust your users, then you need to set limits for them. If you do trust your users, then you don't.
Capiche?
man ulimit
Specifically ulimit -H -u <number> in their startup file.
Maybe I'm just biased, because last year, I had a horrible time overcoming some hard-coded limits (on stack size) when trying to run some Fortran code on a SunOS box.
Your sensible defaults (which you're still loathe to define) haven't help our server admin. They do prevent a fork bomb, but they might well also stop me from running my own user-space code, if it doesn't meet the expectations of a distro-writer who I've never met.
I get to decide who has an account on my machine. Therefore, I trust everyone who has an account on my machine.
I do not trust everyone with access to a win2000 boot CD.
Users use resources. If an admin wants to starve their untrustworthy users of resources, they can (and, if they've a lot of untrustworthy users, its highly recommended), but there is simply no compelling reason why it should be turned on by default.
i) My hardware
ii) How many users I want
iii) What programs / services will be running,
how in the name of crikey are they supposed to determine what a "Reasonable limit" would be?
Sorry, brain fart. I meant hard ulimits
Sorry but the ability for a non-privileged user to run as many programs as the like is a feature, not a bug. Inability to turn that feature off would be a bug, but given that few modern Linux boxes are actually used as multi-user remote-login accounts, it's a completely unecessary overhead.
And if you are administrating a true multi-user old-style-Unix type server, you should know enough to stop people fork bombing you (i.e. quotas).