Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932426AbWBTKBh (ORCPT ); Mon, 20 Feb 2006 05:01:37 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S932435AbWBTKBh (ORCPT ); Mon, 20 Feb 2006 05:01:37 -0500 Received: from mailhub.sw.ru ([195.214.233.200]:26665 "EHLO relay.sw.ru") by vger.kernel.org with ESMTP id S932426AbWBTKBg (ORCPT ); Mon, 20 Feb 2006 05:01:36 -0500 Message-ID: <43F991DC.8010509@sw.ru> Date: Mon, 20 Feb 2006 12:54:36 +0300 From: Kirill Korotaev User-Agent: Mozilla/5.0 (X11; U; Linux i686; ru-RU; rv:1.2.1) Gecko/20030426 X-Accept-Language: ru-ru, en MIME-Version: 1.0 To: "Serge E. Hallyn" CC: "Eric W. Biederman" , linux-kernel@vger.kernel.org, vserver@list.linux-vserver.org, Alan Cox , Dave Hansen , Arjan van de Ven , Suleiman Souhlal , Hubertus Franke , Cedric Le Goater , Kyle Moffett , Greg , Linus Torvalds , Andrew Morton , Greg KH , Rik van Riel , Alexey Kuznetsov , Andrey Savochkin , Kirill Korotaev , Andi Kleen , Benjamin Herrenschmidt , Jeff Garzik , Trond Myklebust , Jes Sorensen Subject: Re: (pspace,pid) vs true pid virtualization References: <20060215145942.GA9274@sergelap.austin.ibm.com> <20060216143030.GA27585@MAIL.13thfloor.at> <20060216153729.GB22358@sergelap.austin.ibm.com> In-Reply-To: <20060216153729.GB22358@sergelap.austin.ibm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1744 Lines: 50 >>this is mandatory, as it is required to kill any process >>from the host (admin) context, without entering the pid >>space (which would lead to all kind of security issues) > Just to be clear: you think there should be cases where pspace x can > kill processes in pspace y, but can't enter it? YES! When you have resource management such a situation is quite common. As I wrote in antoher email example: VPS has reached it's process limit and you can't enter it. If you suggest to make enter without resource limitations, then it will be a security hole. >>>- Should we be able to monitor a pid space from the outside? >> >>yes, definitely, but it could happen via some special >>interfaces, i.e. no need to make it compatible > > > What sort of interfaces do you envision for these two? If we > can lay them out well enough, maybe the result will satisfy the > openvz folks? > > For instance, perhaps we just use a proc interface, where in the > current pspace, if we've created a new pspace which in our pspace > is known as process 567, then we might see > > /proc > /proc/567 > /proc/567/pspace > /proc/567/pspace/1 -> link to /proc/567 > /proc/567/pspace/2 > > Now we also might be able to interact with the pspace by doing > something like > > echo -9 > /proc/567/pspace/2/kill > > and of course do things like > > cd /proc/567/pspace/1/root uff... we can start calling ptrace etc. via proc then :) UGLY! I think Linus will ban us for such ideas. And he will be right. Kirill - 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/