Re: [PATCH v2 2/2] namespaces: add transparent user namespaces

From: "Mickaël Salaün" <mic@digikod.net>
To: "Eric W. Biederman" <ebiederm@xmission.com>,
	Jann Horn <jannh@google.com>
Cc: Christoph Lameter <cl@linux.com>,
	Kees Cook <keescook@chromium.org>,
	linux-kernel@vger.kernel.org,
	Linux Containers <containers@lists.linux-foundation.org>,
	Oleg Nesterov <oleg@redhat.com>,
	Calvin Owens <calvinowens@fb.com>,
	Seth Forshee <seth.forshee@canonical.com>,
	John Stultz <john.stultz@linaro.org>,
	Al Viro <viro@zeniv.linux.org.uk>,
	Andy Lutomirski <luto@kernel.org>,
	Cyrill Gorcunov <gorcunov@openvz.org>, Jann Horn <jann@thejh.net>,
	Andrew Morton <akpm@linux-foundation.org>,
	Janis Danisevskis <jdanis@google.com>,
	Alexey Dobriyan <adobriyan@gmail.com>,
	Michael Kerrisk <mtk.manpages@gmail.com>
Subject: Re: [PATCH v2 2/2] namespaces: add transparent user namespaces
Date: Tue, 12 Jul 2016 22:11:17 +0200	[thread overview]
Message-ID: <57854EE5.1030707@digikod.net> (raw)
In-Reply-To: <87mvm6y8g9.fsf@x220.int.ebiederm.org>

[-- Attachment #1.1: Type: text/plain, Size: 2863 bytes --]

Hi,

I have been looking for this kind of feature for StemJail [1]. One of the main idea is to being able to create mount points inside a jail as an unprivileged user but to keep as much as possible the same environment from outside the jail. For now, I can only create a mapping for the current user, so when a process list any files belonging to another user/group it get "nobody", which seems weird from a user point of view :)

Regards,
Mickaël

1. https://github.com/stemjail/stemjail

On 27/06/2016 17:09, Eric W. Biederman wrote:
> 
> Added a few more relevant cc's.
> 
> Jann Horn <jannh@google.com> writes:
> 
>> This allows the admin of a user namespace to mark the namespace as
>> transparent. All other namespaces, by default, are opaque.
> 
> 
> I have just skimmed through this and at a high level this doesn't seem
> too scary.  Having an identity mapped user namespace that just limits
> you to using a subset of uids and gids while allowing displaying the
> full range of uids and gids.
> 
> I don't quite get the use case and I would like to a little better
> but in the long term this shouldn't cause any significant maintenance
> issues, so I don't have any objects.
> 
> At the same time this isn't quite the time to merge this.  I am in the
> process of slowly going through Seth's vfs changes to support things
> such as truly unprivileged fuse support.  Those changes alter which
> places can always be assumed to be init_user_ns (many fewer), and also
> slightly change the set of from_kuid calls being made.
> 
> The changes that have made it through my review currently reside at:
> 
>     git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace.git for-next
> 
> Those vfs changes make it conceivable and simple from an infrastructure
> standpoint to transition fileystems to unprivileged user namespace
> mounts, with perhaps as little work as just setting FS_USER_NS.  At the
> same time that won't be recommend because of the difficulty verifying
> evil filesystem contents can't cause fs implementations to do bad things
> is difficult.
> 
> That change means your first patch that just zaps all from_kuid_munged
> users in init_user_ns isn't a particularly good idea.  I don't think it
> is a good idea to have one set of rules for things that will always be
> init_user_ns and another set of rules for code that will change.
> 
> The long and short of this is I am asking you to wait a week or so and
> rebase this on my for-next branch so that we can confirm this change
> interacts nicely will all of the other on-going work.
> 
> Thank you,
> Eric Biederman
> _______________________________________________
> Containers mailing list
> Containers@lists.linux-foundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/containers
> 

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 455 bytes --]