From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-fsdevel-owner@vger.kernel.org>
Received: from out02.mta.xmission.com ([166.70.13.232]:42590 "EHLO
	out02.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1752844AbcGDQkM (ORCPT
	<rfc822;linux-fsdevel@vger.kernel.org>);
	Mon, 4 Jul 2016 12:40:12 -0400
From: ebiederm@xmission.com (Eric W. Biederman)
To: Jan Kara <jack@suse.cz>
Cc: Seth Forshee <seth.forshee@canonical.com>,
	Linux Containers <containers@lists.linux-foundation.org>,
	linux-fsdevel@vger.kernel.org,
	Linux API <linux-api@vger.kernel.org>,
	James Bottomley <James.Bottomley@HansenPartnership.com>,
	Djalal Harouni <tixxdz@gmail.com>,
	"Serge E. Hallyn" <serge@hallyn.com>,
	Andy Lutomirski <luto@amacapital.net>,
	Jann Horn <jannh@google.com>,
	Michael Kerrisk <mtk.manpages@gmail.com>
References: <87ziq03qnj.fsf@x220.int.ebiederm.org>
	<20160704085220.GC5200@quack2.suse.cz>
Date: Mon, 04 Jul 2016 11:27:46 -0500
In-Reply-To: <20160704085220.GC5200@quack2.suse.cz> (Jan Kara's message of
	"Mon, 4 Jul 2016 10:52:20 +0200")
Message-ID: <87h9c52wsd.fsf@x220.int.ebiederm.org>
MIME-Version: 1.0
Content-Type: text/plain
Subject: Re: [PATCH review 0/11] General unprivileged mount support
Sender: linux-fsdevel-owner@vger.kernel.org
List-ID: <linux-fsdevel.vger.kernel.org>

Jan Kara <jack@suse.cz> writes:

> On Sat 02-07-16 12:18:08, Eric W. Biederman wrote:
>> 
>> As well as in these patches the code is also available from:
>> git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace.git for-testing
>> 
>> It has been a long time in coming but recently in the userns tree the
>> superblock has been expanded with a s_user_ns field indicating the user
>> namespace that owns a superblock.
>> 
>> The s_user_ns owner of a superblock has three implications.
>> - Only kuids and kgids that map into s_user_ns are allowed to be sent to a
>>  filesystem from the vfs.
>> - If the uid or gid on the filesystem does not map into s_user_ns i_uid
>>   is set to INVALID_UID and i_gid is set to INVALID_GID.
>> - The scope of permission checks can be changed from global to a
>>   capabilitiy check in s_user_ns.
>
> OK, to check that I understand it right:
>
> So the uids and gids that are stored on disk are still expected to be in
> the initial id namespace, aren't they?

No.

The general expectation is that the ids on disk are store in s_user_ns.

Id's that don't map to the initial id namespace get stored in the
generic data structures as INVALID_UID and INVALID_GID.

In practice I don't expect anyone will set up a situation knowingly
where id's don't map, but the case has to be handled because mistakes
and malicious code happens.

Eric