Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750824AbWBKJ2j (ORCPT ); Sat, 11 Feb 2006 04:28:39 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751310AbWBKJ2j (ORCPT ); Sat, 11 Feb 2006 04:28:39 -0500 Received: from ebiederm.dsl.xmission.com ([166.70.28.69]:18627 "EHLO ebiederm.dsl.xmission.com") by vger.kernel.org with ESMTP id S1750824AbWBKJ2i (ORCPT ); Sat, 11 Feb 2006 04:28:38 -0500 To: Kirill Korotaev 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> From: ebiederm@xmission.com (Eric W. Biederman) Date: Sat, 11 Feb 2006 02:25:03 -0700 In-Reply-To: <43ECE0AB.1010608@sw.ru> (Kirill Korotaev's message of "Fri, 10 Feb 2006 21:51:23 +0300") Message-ID: User-Agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1985 Lines: 49 Kirill Korotaev writes: > Eric, > > 1. I would rename wid to wpid :) :) > 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. 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. 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. 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...) >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. Eric - 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/