From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <8dfdbb11d09c26a8525146b0ad45d26d@coraid.com>
From: erik quanstrom <quanstro@coraid.com>
Date: Thu, 14 Feb 2008 12:27:19 -0500
To: 9fans@cse.psu.edu
Subject: Re: [9fans] Google search of the day
In-Reply-To: <10011d262a8868a1773f7b7f7b9c9d57@csplan9.rit.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Topicbox-Message-UUID: 53d13844-ead3-11e9-9d60-3106f5b1d025

>
> It's a proper denial of service on Plan 9... I ran it while
> cpu'd into another box and found that somehow it killed *both*
> machines. IIRC, Plan 9 doesn't really have any kind of resource
> limiting, does it? (Yeah, I know, not necessary for a terminal,
> but it should be important for a cpu server)
>

this is a problem for unix and plan 9.  as soon as you try resource
limiting, you have a new way to dos a machine.  force the hostowner
(or root) to use up his allotment.  okay, the unix guys have thought
of this and so they limit the number of ssh connections.  the problem
is that if you access as root to the box is via ssh, you're still done.
i don't see an easy systematic solution to this type of problem.

as was discussed a few months ago, any system that has unreserved
stack allocation can suffer from similiar problems.  the oom killer
on linux is a symptom of this kind of problem.

- erik