On Sat, Dec 07, 2002 at 05:57:31PM -0500, Greg A. Woods wrote:
> [ 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.
> 
> 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.

  For security, sometimes it is useful to treat every user and every
  program as a potential adversary.  Taking the adversarial view, every
  program could be a Trojan horse, and some users are untrustworthy
  strangers.  If I can assign every person and program the least
  privileges they need to do useful work, then I can confidently run an
  executable e-mail attachment which purports to be a useful Photoshop
  filter, or I can give my friend's cousin's friend's brother an account
  with which to practice his C programming, or I can give spare CPU
  cycles to a program which promises to sequence the pterodactyl genome.

  I have a problem with RLIMIT_CPU because there is no setting of it
  with which I can confidently limit the C programming student or the
  genome program to 30 minutes of CPU time.

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

  Almost.  I am looking for recognition that there is a problem which
  cumulative process accounting solves, because I think that solutions
  to non-problems do not belong in NetBSD. =)

Dave

-- 
David Young             OJC Technologies
dyoung@ojctech.com      Engineering from the Right Brain
                        Urbana, IL * (217) 278-3933