From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753272AbcGLWr1 (ORCPT ); Tue, 12 Jul 2016 18:47:27 -0400 Received: from out02.mta.xmission.com ([166.70.13.232]:44418 "EHLO out02.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753177AbcGLWpa convert rfc822-to-8bit (ORCPT ); Tue, 12 Jul 2016 18:45:30 -0400 From: ebiederm@xmission.com (Eric W. Biederman) To: =?utf-8?Q?Micka=C3=ABl_Sala=C3=BCn?= Cc: Michael Kerrisk , Kees Cook , Linux Containers , Oleg Nesterov , Andrew Morton , linux-kernel@vger.kernel.org, Seth Forshee , John Stultz , Al Viro , Andy Lutomirski , Cyrill Gorcunov , Jann Horn , Christoph Lameter , Janis Danisevskis , Calvin Owens , Alexey Dobriyan References: <1466814210-3778-1-git-send-email-jannh@google.com> <1466814210-3778-2-git-send-email-jannh@google.com> <87mvm6y8g9.fsf@x220.int.ebiederm.org> <57854EE5.1030707@digikod.net> Date: Tue, 12 Jul 2016 17:32:22 -0500 In-Reply-To: <57854EE5.1030707@digikod.net> (=?utf-8?Q?=22Micka=C3=ABl_Sal?= =?utf-8?Q?a=C3=BCn=22's?= message of "Tue, 12 Jul 2016 22:11:17 +0200") Message-ID: <87k2gqxzbd.fsf@x220.int.ebiederm.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT X-XM-SPF: eid=1bN6Q6-0001Q0-Q7;;;mid=<87k2gqxzbd.fsf@x220.int.ebiederm.org>;;;hst=in02.mta.xmission.com;;;ip=67.3.204.119;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX1+2fau8LhJ0q28KxD1YPFH3Fg77y2SJA6k= X-SA-Exim-Connect-IP: 67.3.204.119 X-SA-Exim-Mail-From: ebiederm@xmission.com X-Spam-Report: * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP * 0.7 XMSubLong Long Subject * 0.0 TVD_RCVD_IP Message was received from an IP address * 0.0 T_TM2_M_HEADER_IN_MSG BODY: No description available. * 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% * [score: 0.5000] * -0.0 DCC_CHECK_NEGATIVE Not listed in DCC * [sa01 1397; Body=1 Fuz1=1 Fuz2=1] X-Spam-DCC: XMission; sa01 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: =?ISO-8859-1?Q?;Micka=c3=abl Sala=c3=bcn ?= X-Spam-Relay-Country: X-Spam-Timing: total 963 ms - load_scoreonly_sql: 0.05 (0.0%), signal_user_changed: 3.9 (0.4%), b_tie_ro: 2.8 (0.3%), parse: 1.57 (0.2%), extract_message_metadata: 37 (3.8%), get_uri_detail_list: 5 (0.5%), tests_pri_-1000: 12 (1.2%), tests_pri_-950: 2.0 (0.2%), tests_pri_-900: 1.69 (0.2%), tests_pri_-400: 53 (5.5%), check_bayes: 51 (5.3%), b_tokenize: 19 (1.9%), b_tok_get_all: 16 (1.6%), b_comp_prob: 8 (0.8%), b_tok_touch_all: 3.9 (0.4%), b_finish: 0.87 (0.1%), tests_pri_0: 840 (87.2%), check_dkim_signature: 0.94 (0.1%), check_dkim_adsp: 4.6 (0.5%), tests_pri_500: 6 (0.6%), rewrite_mail: 0.00 (0.0%) Subject: Re: [PATCH v2 2/2] namespaces: add transparent user namespaces X-Spam-Flag: No X-SA-Exim-Version: 4.2.1 (built Thu, 05 May 2016 13:38:54 -0600) X-SA-Exim-Scanned: Yes (on in02.mta.xmission.com) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Mickaël Salaün writes: > 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 :) Weird but I have never found it harmful. The big thrashing about with adding s_user_ns is complete in my tree so I can accept a reasonable patch, and transparent user namespaces is on the edge. If transparent user namespaces solve anything except for weird. They are simple enough that given a good quality patch I will merge them. Still I want to make certain they solve something real or else I am not certain the added complexity is worth the maintenance burden. Especially in a part of the code where getting confused and making small mistakes results in security issues. On the flip side it isn't that much weirder than from_kuid_munged today so it may not be any kind of problem at all. > > 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 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 Eric