From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kara Subject: Re: [PATCH review 07/11] vfs: Don't create inodes with a uid or gid unknown to the vfs Date: Wed, 6 Jul 2016 11:07:05 +0200 Message-ID: <20160706090705.GE14067@quack2.suse.cz> References: <87ziq03qnj.fsf@x220.int.ebiederm.org> <20160702172035.19568-1-ebiederm@xmission.com> <20160702172035.19568-7-ebiederm@xmission.com> <20160704075919.GA5200@quack2.suse.cz> <87zipwxhgp.fsf@x220.int.ebiederm.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <87zipwxhgp.fsf-JOvCrm2gF+uungPnsOpG7nhyD016LWXt@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: containers-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org Errors-To: containers-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org To: "Eric W. Biederman" Cc: Jan Kara , Jann Horn , Linux API , Linux Containers , Andy Lutomirski , James Bottomley , Seth Forshee , Michael Kerrisk , linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Djalal Harouni List-Id: containers.vger.kernel.org On Tue 05-07-16 09:55:18, Eric W. Biederman wrote: > Jan Kara writes: > > > On Sat 02-07-16 12:20:31, Eric W. Biederman wrote: > >> It is expected that filesystems can not represent uids and gids from > >> outside of their user namespace. Keep things simple by not even > >> trying to create filesystem nodes with non-sense uids and gids. > >> > >> Signed-off-by: "Eric W. Biederman" > > > > So if we have sb->s_user_ns that doesn't map UID and GID 0, root cannot > > directly create files in this filesystem. EOVERFLOW error will at least > > hint us where the problem is but still I'm suspecting this is going to > > create hard to debug configuration issues... I'm not sure if we can do > > anything about this but I wanted to point it out. > > A reasonable point. > > A couple of details. > > - If there is no uid or gid 0 inside of a user namespace there is > no root user in that namespace so this is a moot point. > > - If we are talking about uid 0 in the initial user namespace the > scenario you are worried about can occur, but you have to work at it > to get into that situation. > > To create a superblock has s_user_ns != &init_user_ns something like > the following has to occur. > > setuid(1000); > unshare(CLONE_NEWUSER); > unshare(CLONE_NEWNS); > mount(....); > > At which point the oridinary root user can not see the filesystem > with s_user_ns != &init_user_ns as it is located in another mount > namespace. > > Which means root has to use setns to get into that mount namespace, > so there are going to be larger hints than -EOVERFLOW. OK, I see. Thanks for explanation. The inability of the admin (UID 0 in init_user_ns) to easily see and change any filesystem mounted in the system makes me somewhat nervous ;). But I guess the complexity is the price for the flexibility... Honza -- Jan Kara SUSE Labs, CR From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx2.suse.de ([195.135.220.15]:34576 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751258AbcGFJXq (ORCPT ); Wed, 6 Jul 2016 05:23:46 -0400 Date: Wed, 6 Jul 2016 11:07:05 +0200 From: Jan Kara To: "Eric W. Biederman" Cc: Jan Kara , Seth Forshee , Linux Containers , linux-fsdevel@vger.kernel.org, Linux API , James Bottomley , Djalal Harouni , "Serge E. Hallyn" , Andy Lutomirski , Jann Horn , Michael Kerrisk Subject: Re: [PATCH review 07/11] vfs: Don't create inodes with a uid or gid unknown to the vfs Message-ID: <20160706090705.GE14067@quack2.suse.cz> References: <87ziq03qnj.fsf@x220.int.ebiederm.org> <20160702172035.19568-1-ebiederm@xmission.com> <20160702172035.19568-7-ebiederm@xmission.com> <20160704075919.GA5200@quack2.suse.cz> <87zipwxhgp.fsf@x220.int.ebiederm.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87zipwxhgp.fsf@x220.int.ebiederm.org> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Tue 05-07-16 09:55:18, Eric W. Biederman wrote: > Jan Kara writes: > > > On Sat 02-07-16 12:20:31, Eric W. Biederman wrote: > >> It is expected that filesystems can not represent uids and gids from > >> outside of their user namespace. Keep things simple by not even > >> trying to create filesystem nodes with non-sense uids and gids. > >> > >> Signed-off-by: "Eric W. Biederman" > > > > So if we have sb->s_user_ns that doesn't map UID and GID 0, root cannot > > directly create files in this filesystem. EOVERFLOW error will at least > > hint us where the problem is but still I'm suspecting this is going to > > create hard to debug configuration issues... I'm not sure if we can do > > anything about this but I wanted to point it out. > > A reasonable point. > > A couple of details. > > - If there is no uid or gid 0 inside of a user namespace there is > no root user in that namespace so this is a moot point. > > - If we are talking about uid 0 in the initial user namespace the > scenario you are worried about can occur, but you have to work at it > to get into that situation. > > To create a superblock has s_user_ns != &init_user_ns something like > the following has to occur. > > setuid(1000); > unshare(CLONE_NEWUSER); > unshare(CLONE_NEWNS); > mount(....); > > At which point the oridinary root user can not see the filesystem > with s_user_ns != &init_user_ns as it is located in another mount > namespace. > > Which means root has to use setns to get into that mount namespace, > so there are going to be larger hints than -EOVERFLOW. OK, I see. Thanks for explanation. The inability of the admin (UID 0 in init_user_ns) to easily see and change any filesystem mounted in the system makes me somewhat nervous ;). But I guess the complexity is the price for the flexibility... Honza -- Jan Kara SUSE Labs, CR