From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756846AbcGIS1v (ORCPT ); Sat, 9 Jul 2016 14:27:51 -0400 Received: from out02.mta.xmission.com ([166.70.13.232]:49513 "EHLO out02.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756588AbcGIS1t (ORCPT ); Sat, 9 Jul 2016 14:27:49 -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> Date: Sat, 09 Jul 2016 13:15:19 -0500 In-Reply-To: <20160709072627.GA7480@outlook.office365.com> (Andrew Vagin's message of "Sat, 9 Jul 2016 00:26:28 -0700") Message-ID: <87eg72llu0.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=1bLwye-0007Fm-Jv;;;mid=<87eg72llu0.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/LpK0LONacOYTJn/aC+jsc62FHiVD5HtE= 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: ;Andrew Vagin X-Spam-Relay-Country: X-Spam-Timing: total 1078 ms - load_scoreonly_sql: 0.06 (0.0%), signal_user_changed: 3.9 (0.4%), b_tie_ro: 2.7 (0.3%), parse: 1.32 (0.1%), extract_message_metadata: 26 (2.4%), get_uri_detail_list: 2.3 (0.2%), tests_pri_-1000: 8 (0.8%), tests_pri_-950: 2.0 (0.2%), tests_pri_-900: 1.60 (0.1%), tests_pri_-400: 30 (2.8%), check_bayes: 28 (2.6%), b_tokenize: 11 (1.0%), b_tok_get_all: 7 (0.7%), b_comp_prob: 4.0 (0.4%), b_tok_touch_all: 2.8 (0.3%), b_finish: 0.90 (0.1%), tests_pri_0: 487 (45.2%), check_dkim_signature: 1.52 (0.1%), check_dkim_adsp: 4.7 (0.4%), tests_pri_500: 512 (47.5%), poll_dns_idle: 504 (46.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 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.) Eric