"Then don't blame the distribution or the kernel."

Should I not blame Microsoft for running services by default that allow remote compromise? Sure, the severity of this attack is much different, but you're still dealing with something that can and should be fixed by the developers.

"On a server - You SHOULD decide how much to support for YOUR workload. Vendors cannot determine that."

I totally agree with you. This is why people who build Internet-connected servers should be bumping up the defaults. There's no good reason to allow a normal user to run 7000 processes by default.

"Nobody wants to be memory limited"

Some people hate not being root.

2. Nobody wants to see "cannot fork" messages for the same reason. "cannot fork - no process space", though usually it just says "no memory" because that is simpler to explain; and is true from a certain point of view - memory for an additional process slot is not available.

"Since people are NOT willing to spend the money to guarantee no resource starvation occurs, they MUST accept the occasional hang."

I'm not saying that if you run a 500 user server, that you should have enough memory to support each user running the maximum number of processes, and each of those processes consuming the maximum amount of allocatable memory. I'm saying that ONE user should not have the power to kill a Unix machine so easily by default. Allowing this to happen means that the default settings are wrong, plain and simple.

"So your system wasn't down. It didn't crash. It WAS a DOS, but obviously a preventable one had the resource limits been restricted to what you could physically support."

Crash was added by the editor, but yes, it didn't crash (which to me would mean a panic() or spontaneous reboot), but it WAS down -- it was totally unusable for at least two or three hours.

[ reply ]

Link to this comment: http://www.securityfocus.com/comments/columns/308/30988#30988