3 ms·

I agree that there are already many ways to DoS the system-- for example, the age-old fork bomb. But that is not a good reason to add more flaws. People are w

I agree that there are already many ways to DoS the system-- for example, the age-old fork bomb. But that is not a good reason to add more flaws. People are working on ways to fix the old flaws, such as cgroups. I don't think a ulimit would be very effective here at preventing denial-of-service. Let's say I set it to 100... I can just have my 100 children each spawn and hold on to 100 children of their own, and so on and so forth. If I just go with a bigger process ID space all these headaches go away, plus existing software works without modification.

quotemstr 11y ago
32 bits is still too small. I wouldn't be comfortable relying on the size of the PID space to avoid collisions until we made it 128 bits or so. I think you're still seriously overestimating the danger of a DoS here: whatever limits apply to forked processes can apply to process handles. Whatever mitigates fork bombs will also mitigate handle-based attacks. The advantages of process handles outweigh this small risk.
- Dylan16807 11y ago
  In what scenario would you run out of 64 bit PIDs? How many per second for how many centuries?
  - quotemstr 11y ago
    It's not a matter of running out of PIDs: it's about the probability of accidental collision.
Dylan16807 11y ago
A workable limit is trivial, how about 100 zombie process IDs per user.