From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932899AbcGIAEq (ORCPT ); Fri, 8 Jul 2016 20:04:46 -0400 Received: from out03.mta.xmission.com ([166.70.13.233]:58808 "EHLO out03.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932595AbcGIAEh (ORCPT ); Fri, 8 Jul 2016 20:04:37 -0400 From: ebiederm@xmission.com (Eric W. Biederman) To: James Bottomley Cc: Andrew Vagin , Linux API , Containers , lkml , criu@openvz.org, "Michael Kerrisk \(man-pages\)" References: <87r3b7pxja.fsf@x220.int.ebiederm.org> <20160706141348.GB20728@mail.hallyn.com> <871t36kbvq.fsf@x220.int.ebiederm.org> <20160708015758.GA10512@outlook.office365.com> <87vb0gy3nr.fsf@x220.int.ebiederm.org> <1467988533.2322.118.camel@HansenPartnership.com> <20160708203818.GA2602@outlook.office365.com> <5e4cc802-f0e0-4f4c-a2f7-585aaaa8feec@email.android.com> Date: Fri, 08 Jul 2016 18:52:09 -0500 In-Reply-To: <5e4cc802-f0e0-4f4c-a2f7-585aaaa8feec@email.android.com> (James Bottomley's message of "Fri, 08 Jul 2016 15:19:28 -0700") Message-ID: <87wpkvpu1i.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 X-XM-SPF: eid=1bLfl3-00025O-N6;;;mid=<87wpkvpu1i.fsf@x220.int.ebiederm.org>;;;hst=in01.mta.xmission.com;;;ip=67.3.204.119;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX1+JokvwLZIEDPo+slcng7uIGyUAc8NTNhc= 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.0 TVD_RCVD_IP Message was received from an IP address * 0.7 XMSubLong Long Subject * 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 * [sa06 1397; Body=1 Fuz1=1 Fuz2=1] X-Spam-DCC: XMission; sa06 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: ;James Bottomley X-Spam-Relay-Country: X-Spam-Timing: total 1044 ms - load_scoreonly_sql: 0.04 (0.0%), signal_user_changed: 4.1 (0.4%), b_tie_ro: 3.0 (0.3%), parse: 0.93 (0.1%), extract_message_metadata: 15 (1.5%), get_uri_detail_list: 1.10 (0.1%), tests_pri_-1000: 6 (0.6%), tests_pri_-950: 1.19 (0.1%), tests_pri_-900: 1.03 (0.1%), tests_pri_-400: 20 (1.9%), check_bayes: 18 (1.8%), b_tokenize: 4.8 (0.5%), b_tok_get_all: 6 (0.6%), b_comp_prob: 1.81 (0.2%), b_tok_touch_all: 3.1 (0.3%), b_finish: 0.75 (0.1%), tests_pri_0: 143 (13.7%), check_dkim_signature: 0.70 (0.1%), check_dkim_adsp: 10 (0.9%), tests_pri_500: 850 (81.4%), poll_dns_idle: 844 (80.8%), rewrite_mail: 0.00 (0.0%) Subject: Re: [CRIU] Introspecting userns relationships to other 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 in01.mta.xmission.com) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org James Bottomley writes: > On July 8, 2016 1:38:19 PM PDT, Andrew Vagin wrote: >>What do you think about the idea to mount nsfs and be able to look up >>any alive namespace by inum: > > I think I like it. It will give us a way to enter any extant > namespace. It will work for Eric's fs namespaces as well. Perhaps a > /process/ns/ Directory? *Shivers* That makes it very easy to bypass any existing controls that exist for getting at namespaces. It is true that everything of that kind is directory based but still. Plus I think it would serve as information leak to information outside of the container. An operation to get a user namespace file descriptor from some kernel object sounds reasonably sane. A great big list of things sounds about as scary as it can get. This is not the time to be making it easier to escape from containers. Eric