Date: Mon, 12 Jan 2009 16:19:31 +0000
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
To: Evgeniy Polyakov <zbr@ioremap.net>
Cc: linux-kernel@vger.kernel.org, Andrew Morton <akpm@linux-foundation.org>,
       Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: Linux killed Kenny, bastard!
Message-ID: <20090112161931.6203f96e@lxorguk.ukuu.org.uk>
In-Reply-To: <20090112155615.GA21350@ioremap.net>
References: <20090112153304.GA19995@ioremap.net>
	<20090112154922.6003750b@lxorguk.ukuu.org.uk>
	<20090112155030.GA21063@ioremap.net>
	<20090112155239.5f677a17@lxorguk.ukuu.org.uk>
	<20090112155615.GA21350@ioremap.net>
Organization: Red Hat UK Cyf., Amberley Place, 107-111 Peascod Street,
 Windsor, Berkshire, SL4 1TE, Y Deyrnas Gyfunol. Cofrestrwyd yng Nghymru a
 Lloegr o'r rhif cofrestru 3798903
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 957
Lines: 19

> Yes, it could be done. If inotify will not be killed itself, will be
> enabled in the config and daemon will be started.
> But right now there is no way to solve that task, in the long term this
> is a good idea to implement modulo security problems it may concern.

It is perfectly soluble right now, use the existing /proc interface. If
you want to specifically victimise new tasks first then set everything
else with an adjust *against* being killed and new stuff will start off
as cannon fodder until classified.

The name approach is the wrong way to handle this. It has no reflection
of heirarchy of process, targetting by users, containers etc.. 

In fact containers are probably the right way to do it
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/