From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756818AbcGISlw (ORCPT ); Sat, 9 Jul 2016 14:41:52 -0400 Received: from out01.mta.xmission.com ([166.70.13.231]:38305 "EHLO out01.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756588AbcGISlu (ORCPT ); Sat, 9 Jul 2016 14:41:50 -0400 From: ebiederm@xmission.com (Eric W. Biederman) To: Andrew Vagin Cc: James Bottomley , Linux API , Containers , lkml , , "Michael Kerrisk \(man-pages\)" References: <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> <87wpkvpu1i.fsf@x220.int.ebiederm.org> <1468023332.2390.10.camel@HansenPartnership.com> <87bn27o6j5.fsf@x220.int.ebiederm.org> <20160709072627.GA7480@outlook.office365.com> <87eg72llu0.fsf@x220.int.ebiederm.org> Date: Sat, 09 Jul 2016 13:29:20 -0500 In-Reply-To: <87eg72llu0.fsf@x220.int.ebiederm.org> (Eric W. Biederman's message of "Sat, 09 Jul 2016 13:15:19 -0500") Message-ID: <871t32ll6n.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=1bLxCD-0007sQ-4j;;;mid=<871t32ll6n.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+6okv9qxSoCmepXxZX9RQZDZYzgdBgm6Q= 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: ;Andrew Vagin X-Spam-Relay-Country: X-Spam-Timing: total 1055 ms - load_scoreonly_sql: 0.03 (0.0%), signal_user_changed: 8 (0.8%), b_tie_ro: 6 (0.6%), parse: 0.72 (0.1%), extract_message_metadata: 14 (1.3%), get_uri_detail_list: 1.72 (0.2%), tests_pri_-1000: 7 (0.7%), tests_pri_-950: 1.14 (0.1%), tests_pri_-900: 0.97 (0.1%), tests_pri_-400: 21 (2.0%), check_bayes: 20 (1.9%), b_tokenize: 6 (0.5%), b_tok_get_all: 7 (0.7%), b_comp_prob: 2.0 (0.2%), b_tok_touch_all: 2.9 (0.3%), b_finish: 0.69 (0.1%), tests_pri_0: 206 (19.5%), check_dkim_signature: 0.67 (0.1%), check_dkim_adsp: 3.1 (0.3%), tests_pri_500: 792 (75.1%), poll_dns_idle: 785 (74.5%), 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 in02.mta.xmission.com) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org ebiederm@xmission.com (Eric W. Biederman) writes: > Andrew Vagin writes: > >> All these thoughts about security make me thinking that kcmp is what we >> should use here. It's maybe something like this: >> >> kcmp(pid1, pid2, KCMP_NS_USERNS, fd1, fd2) >> >> - to check if userns of the fd1 namepsace is equal to the fd2 userns >> >> kcmp(pid1, pid2, KCMP_NS_PARENT, fd1, fd2) >> >> - to check if a parent namespace of the fd1 pidns is equal to fd pidns. >> >> fd1 and fd2 is file descriptors to namespace files. >> >> So if we want to build a hierarchy, we need to collect all namespaces >> and then enumerate them to check dependencies with help of kcmp. > > That is certainly one way to go. > > There is a funny case where we would want to compare a user namespace > file descriptor to a parent user namespace file descriptor. > > > Grumble, Grumble. I think this may actually a case for creating ioctls > for these two cases. Now that random nsfs file descriptors are bind > mountable the original reason for using proc files is not as pressing. > > One ioctl for the user namespace that owns a file descriptor. > One ioctl for the parent namespace of a namespace file descriptor. > > We also need some way to get a command file descriptor for a file system > super block. Al Viro has a pet project for cleaning up the mount API > and this might be the idea excuse to start looking at that. > > (In principle we might be able to run commands through the namespace > file descriptor and using an ioctl feels dirty. But an ioctl that > only uses the fd and request argument does not suffer from the same > problems that ioctls that have to pass additional arguments suffer > from.) Of course it should be an error perhaps -EINVAL to get a user namespace owner or parent namespace that is outside of a processes current user namespace or pid namespace. That way thing stay bounded within the current namespaces the process is in. Which prevents any leak possibilities, and keeps CRIU working. Eric