> >...with great effort and a bit of luck, if he can get at the require=
d
> >CPU resources, which would be difficult because the fork bomb
> >processes are at this point (without the patch) all spinning doing a=

> >system call -- fork().
>
> But, you have the same problem if you have 2000 programs doing:
>
> 	for (;;)
> 		getpid();

True.  I never said that the patch as proposed would be the solution
to solve all local DoS attacks.  However, it deals with the fork
variant of it.

I've been exposed to more than one instance where the fork bomb was
more of an accident ("novice learning experience") than an actual
malicious attack.  It's harder to see how the above program could
first become 2000 processes and then spin doing getpid() as an
accident or misunderstanding.

> or any other system call.  Why should fork(2) be special?  Just
> because there is an old local DOS attack that used it?

Yep.

If a single program is spinning doing getpid(), that's no big deal.

If you have 2000 processes all spinning in fork(), that *is* a big
deal when it comes to dealing with it as an administrator, that is,
before this patch.

> If a process or a number of processes can kill the machine just by
> spinning on forks that always fail, then I believe that this
> underlines a more serious issue that should be addressed and not
> papered over.

Maybe.

> If consensus is to penalise the offending process, I'd like to put
> forward the notion of just adding a large number to p_estcpu rather
> than tsleeping.  At least then the solution would work within the
> current scheduler to some degree.

Wouldn't that make some of the statistics shown by e.g. ps misleading?
If so, I don't see that as a particularly elegant solution, at least
not compared to the current proposal.

Regards,

- H=E5vard