[ On Saturday, December 7, 2002 at 01:52:03 (-0600), David Young wrote: ]
> Subject: Re: Fork bomb protection patch
>
>   That's what I thought: RLIMIT_CPU * RLIMIT_NPROC is not the limit on
>   the number of CPU seconds that a fork bomb can consume in its lifetime.
>   A fork bomb may consume many times the RLIMIT_CPU of any single process
>   constituting the bomb---infinitely many times, really. The bomb need
>   only fork one process for every process that hits its CPU time limit,
>   and it will go forever.  I don't like that at all. =)

I don't see why you have any problem with it.  There's no general reason
why a user shouldn't be allowed to continue to consume all the resources
granted to them for the lifetime of the system -- certainly not general
enough that it deserves to be implemented in a kernel that already
supports setrlimit() et al.

If there's a policy that says users shouldn't waste cycles on thinks
like silly fork-bombs then that's a very different issue and the
solution is very much outside the scope of the kernel (though as I
mentioned before there are tools such as realtime accounting that might
help remind the user of the external policy rules).

After all, the user can't do any other useful work while running the
fork-bomb if it consumes all of his or her authorised resources!  ;-)

>   Ok. Is it fair to say that we both believe in the Law, but I prefer
>   that the Law is the Law of Physics (CPU seconds can neither be created
>   nor destroyed) and you prefer that the Law is the Law of the Sysadmin
>   (don't get caught cheating on your CPU seconds) ? There are pros and
>   cons for each.

I think you're looking for the realtime cumulative process accounting
feature that I mentioned Multics had....  There's nothing new under this
sun!  ;-)

-- 
								Greg A. Woods

+1 416 218-0098;            <g.a.woods@ieee.org>;           <woods@robohack.ca>
Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>