From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out01.mta.xmission.com ([166.70.13.231]:58651 "EHLO out01.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933243AbcGEPJU (ORCPT ); Tue, 5 Jul 2016 11:09:20 -0400 From: ebiederm@xmission.com (Eric W. Biederman) To: Jan Kara Cc: Seth Forshee , Linux Containers , linux-fsdevel@vger.kernel.org, Linux API , James Bottomley , Djalal Harouni , "Serge E. Hallyn" , Andy Lutomirski , Jann Horn , Michael Kerrisk References: <87ziq03qnj.fsf@x220.int.ebiederm.org> <20160702172035.19568-1-ebiederm@xmission.com> <20160702172035.19568-7-ebiederm@xmission.com> <20160704075919.GA5200@quack2.suse.cz> Date: Tue, 05 Jul 2016 09:55:18 -0500 In-Reply-To: <20160704075919.GA5200@quack2.suse.cz> (Jan Kara's message of "Mon, 4 Jul 2016 09:59:19 +0200") Message-ID: <87zipwxhgp.fsf@x220.int.ebiederm.org> MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [PATCH review 07/11] vfs: Don't create inodes with a uid or gid unknown to the vfs Sender: linux-fsdevel-owner@vger.kernel.org List-ID: 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. At the same time if there are better error codes that make it clearer what is happening I am all ears. Eric