Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757076AbYCBBQN (ORCPT ); Sat, 1 Mar 2008 20:16:13 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752221AbYCBBP7 (ORCPT ); Sat, 1 Mar 2008 20:15:59 -0500 Received: from ebiederm.dsl.xmission.com ([166.70.28.69]:41765 "EHLO ebiederm.dsl.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751853AbYCBBP6 (ORCPT ); Sat, 1 Mar 2008 20:15:58 -0500 From: ebiederm@xmission.com (Eric W. Biederman) To: "Serge E. Hallyn" Cc: Ian Kent , Jeff Moyer , Andrew Morton , Kernel Mailing List , autofs mailing list , linux-fsdevel , Pavel Emelyanov , "Eric W. Biederman" Subject: Re: [PATCH 3/4] autofs4 - track uid and gid of last mount requestor References: <20080227204546.72e16e8d.akpm@linux-foundation.org> <1204179747.3501.21.camel@raven.themaw.net> <20080227223734.caab0165.akpm@linux-foundation.org> <1204182500.3501.49.camel@raven.themaw.net> <20080227232339.af6e904a.akpm@linux-foundation.org> <1204185623.3501.84.camel@raven.themaw.net> <20080228195118.GA16634@sergelap.austin.ibm.com> <1204255932.3969.86.camel@raven.themaw.net> <20080229160921.GA24296@sergelap.ibm.com> Date: Sat, 01 Mar 2008 18:13:51 -0700 In-Reply-To: <20080229160921.GA24296@sergelap.ibm.com> (Serge E. Hallyn's message of "Fri, 29 Feb 2008 10:09:21 -0600") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2191 Lines: 59 "Serge E. Hallyn" writes: > > The way the user namespaces work right now is similar to say the IPC > namespace - a task belongs to one user, that user belongs to precisely > one user namespace. > > Even in my additional userns patches, I was changing uid to store the > (uid, userns) so a struct user still belonged to just one user > namespace. > > In contrast, with pid namespaces a task is associated with a 'struct > pid' which links it to multiple process ids, one in each pid namespace > to which it belongs. > > Perhaps we should be treating user namespaces like pid namespaces? > > For autofs this would mean that when autofs wants a uid for some task, > it would be given the uid in the user namespace which autofs 'knows'. > > It would also help me fix the siginfo problems I haven't solved yet - > rather than having to worry about user namespace lifetimes with siginfos > (which last a little while but have no clearly defined lifespan) we > could send the uid in an init user namespace or the uid in the target > uid namespace, or just a lightweight user struct proxy akin to 'struct > pid'. > > And it also obviates the need for any sort of delegation. > > So if I'm user 500 in what I think is the initial user namespace, I can > create a container with a new user namespace, the init task of which is > both uid 0 in the child userns, and uid 500 in the higher level, > automatically giving the container access to any files I own. > > Eric, when you get a chance (I know you're overloaded atm) I'd love to > hear your thoughts on this... Succinctly. I think the concept of mapping uids between user namespaces is fundamental to properly describing and thinking about the semantics of user namespaces correct. We don't have to start out anything except handling the case when no mapping exists, but asking the question how does this uid map between from one namespace to another is fundamental. 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/