From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-fsdevel-owner@vger.kernel.org>
Received: from out03.mta.xmission.com ([166.70.13.233]:34684 "EHLO
	out03.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1754974AbcGFPdk (ORCPT
	<rfc822;linux-fsdevel@vger.kernel.org>);
	Wed, 6 Jul 2016 11:33:40 -0400
From: ebiederm@xmission.com (Eric W. Biederman)
To: Andy Lutomirski <luto@amacapital.net>
Cc: Seth Forshee <seth.forshee@canonical.com>,
	Linux Containers <containers@lists.linux-foundation.org>,
	Linux FS Devel <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>, Jan Kara <jack@suse.cz>,
	Jann Horn <jannh@google.com>,
	Michael Kerrisk <mtk.manpages@gmail.com>
References: <87ziq03qnj.fsf@x220.int.ebiederm.org>
	<CALCETrVof174gPCZnD2Z-RMjR-P=NcA0mYCU9ki6=o9hpFL-BA@mail.gmail.com>
Date: Wed, 06 Jul 2016 10:21:02 -0500
In-Reply-To: <CALCETrVof174gPCZnD2Z-RMjR-P=NcA0mYCU9ki6=o9hpFL-BA@mail.gmail.com>
	(Andy Lutomirski's message of "Wed, 6 Jul 2016 06:44:55 -0700")
Message-ID: <87poqqlrmp.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>

Andy Lutomirski <luto@amacapital.net> writes:

> On Sat, Jul 2, 2016 at 10:18 AM, Eric W. Biederman
> <ebiederm@xmission.com> 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
>>
>
> Minor nit: in "fs: Refuse uid/gid changes which don't map into
> s_user_ns", the changelog ends in the middle of a sentence.

This text?
> For filesystems mounted from a user namespace on-disk ids should
> be translated relative to s_users_ns rather than init_user_ns.

> When an id in the filesystem doesn't exist in s_user_ns the
> associated id in the inode will be set to INVALID_[UG]ID, which
> turns these into de facto "nobody" ids. This actually maps pretty
> well into the way most code already works, and those places where
> it didn't were fixed in previous patches. Moving forward vfs code
> needs to be careful to handle instances where ids in inodes may
> be invalid.


I don't see the changelog problem you are talking about.

Eric