Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751348AbWBMInp (ORCPT ); Mon, 13 Feb 2006 03:43:45 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751354AbWBMIno (ORCPT ); Mon, 13 Feb 2006 03:43:44 -0500 Received: from mailhub.sw.ru ([195.214.233.200]:21397 "EHLO relay.sw.ru") by vger.kernel.org with ESMTP id S1751348AbWBMIno (ORCPT ); Mon, 13 Feb 2006 03:43:44 -0500 Message-ID: <43F046B0.7020702@sw.ru> Date: Mon, 13 Feb 2006 11:43:28 +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: "Eric W. Biederman" CC: linux-kernel@vger.kernel.org, vserver@list.linux-vserver.org, Herbert Poetzl , "Serge E. Hallyn" , 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: [RFC][PATCH 01/20] pid: Intoduce the concept of a wid (wait id) References: <43ECE0AB.1010608@sw.ru> In-Reply-To: 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: 2659 Lines: 57 >>2. Maybe I'm missing something in the discussions, but why is it required? if >>you provide fully isolated pid spaces, why do you care for wid? >>And how ptrace can work at all if cldstop reports some pid, but child is not >>accessiable via ptrace()? and if it doesn't work, what are your changes for? > > > A good question. > > My pid spaces while isolated from each other are connected together in > something that resembles the mount relationship when mounting a filesystem. why? is it really required? doing it this way, you get all the issues with external refs we have with a weak isolation, i.e. pspace init can be seen from outside and inside (correct? or am I wrong?). This makes your approach eseentially the same as ours from checkpointing point of view BTW. > The init process of a child pspace is visible in the parent pspace, > by it's wid. So you should be able to ptrace pid == 1. The other > children remain inaccessible directly. > > The idea was to do my very best to preserve the unix process tree when > constructing a separate pid space This more looks like you were trying to make less changes with it and avoid fixing issus which can arise when pspaces are fully isolated. Maybe I'm wrong. > I have to admit I have not yet tested the ptrace corner case, or > digested all of it's ramifications. Unless I have messed up somewhere > it should just work. > > This visibility of the child tree by a single pid inside the parent > tree is why I think my approach doesn't suffer from most of the > problems a completely isolated pid space has. which problems? Actually I can't see much problems with isolated pid spaces. And isolated pid spaces doesn't require hierarchy, since they are fully isolated. > In fact I would even be willing to look at it as a global but > hierarchical pid space if that proved an interesting case. > So you could have something like pkill(int sig, int which, char *pid_path). > Where pid_path is something like "1537/3/58", and which specified > what kind of pid you are talking about (thread, pid, process group...) And here you need to introduce new non-unix semantics, security checks on lookups, etc. >>From a security stand point I want the option of a fully isolated > group of processes, so there is a possibility of keeping secrets from > the system administrator, but there is no reason that needs to be tied > to a pid space. 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/