From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751105AbWGLMFJ (ORCPT ); Wed, 12 Jul 2006 08:05:09 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751161AbWGLMFJ (ORCPT ); Wed, 12 Jul 2006 08:05:09 -0400 Received: from MAIL.13thfloor.at ([212.16.62.50]:42405 "EHLO mail.13thfloor.at") by vger.kernel.org with ESMTP id S1751105AbWGLMFH (ORCPT ); Wed, 12 Jul 2006 08:05:07 -0400 Date: Wed, 12 Jul 2006 14:05:05 +0200 From: Herbert Poetzl To: "Eric W. Biederman" Cc: Cedric Le Goater , linux-kernel@vger.kernel.org, Andrew Morton , Kirill Korotaev , Andrey Savochkin , Sam Vilain , "Serge E. Hallyn" , Dave Hansen Subject: Re: [PATCH -mm 5/7] add user namespace Message-ID: <20060712120505.GA31709@MAIL.13thfloor.at> Mail-Followup-To: "Eric W. Biederman" , Cedric Le Goater , linux-kernel@vger.kernel.org, Andrew Morton , Kirill Korotaev , Andrey Savochkin , Sam Vilain , "Serge E. Hallyn" , Dave Hansen References: <20060711075051.382004000@localhost.localdomain> <20060711075420.937831000@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6i Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jul 11, 2006 at 09:46:01PM -0600, Eric W. Biederman wrote: > Cedric Le Goater writes: > > > This patch adds the user namespace. > > > > Basically, it allows a process to unshare its user_struct table, > > resetting at the same time its own user_struct and all the > > associated accounting. > > > > For the moment, the root_user is added to the new user namespace > > when it is cloned. An alternative behavior would be to let the > > system allocate a new user_struct(0) in each new user namespace. > > However, these 0 users would not have the privileges of the > > root_user and it would be necessary to work on the process > > capabilities to give them some permissions. > > It is completely the wrong thing for a the root_user to span multiple > namespaces as you describe. It is important for uid 0 in other > namespaces to not have the privileges of the root_user. That is half > the point. > > Too many files in sysfs and proc don't require caps but instead simply > limit things to uid 0. Having a separate uid 0 in the different > namespaces instantly makes all of these files inaccessible, and keeps > processes from doing something bad. well, here I'd definitely prefer to fix up that 'broken' entries by adding proper capability checks, and maybe even a bunch of new capabilities (i.e. 64bit caps and such) first, because IMHO the capability system is the 'proper' method to protect them in the first place > To a filesystem a uid does not share a uid namespace with the > only things that should be accessible are those things that are > readable/writeable by everyone. Unless the filesystem has provisions > for storing multiple uid namespaces not files should be able to be > created. Think NFS root squash. that's where file tagging as Linux-VServer does it can be used to 'share' a partition between different guests (and have separate disk limits and quotas) best, Herbert > > Signed-off-by: Cedric Le Goater > > Cc: Andrew Morton > > Cc: Kirill Korotaev > > Cc: Andrey Savochkin > > Cc: Eric W. Biederman > > Cc: Herbert Poetzl > > Cc: Sam Vilain > > Cc: Serge E. Hallyn > > Cc: Dave Hansen > > > > --- > > fs/ioprio.c | 5 + > > include/linux/init_task.h | 2 > > include/linux/nsproxy.h | 2 > > include/linux/sched.h | 6 +- > > include/linux/user.h | 45 +++++++++++++++ > > init/Kconfig | 8 ++ > > kernel/nsproxy.c | 15 ++++- > > kernel/sys.c | 8 +- > > kernel/user.c | 135 ++++++++++++++++++++++++++++++++++++++++++---- > > This patch looks extremly incomplete. > > Every comparison of a user id needs to compare the tuple > (user namespace, user id) or it needs to compare struct users. > > Ever comparison of a group id needs to compare the tuple > (user namespace, group id) or it needs to compare struct users. > > I think the key infrastructure needs to be looked at here as well. > > There needs to be a user namespace association for mounted filesystems. > > We need a discussion about how we handle map users from one user > namespace to another, because without some form of mapping so many > things become inaccessible that the system is almost useless. > > I believe some of the key infrastructure which is roughly kerberos > authentication tokens could be used for this purpose. > > A user namespace is a big thing. What I see here doesn't even > seem to scratch the surface. > > Eric