From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752535AbcGYNcG (ORCPT ); Mon, 25 Jul 2016 09:32:06 -0400 Received: from out01.mta.xmission.com ([166.70.13.231]:42095 "EHLO out01.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752331AbcGYNbz convert rfc822-to-8bit (ORCPT ); Mon, 25 Jul 2016 09:31:55 -0400 From: ebiederm@xmission.com (Eric W. Biederman) To: "Michael Kerrisk \(man-pages\)" Cc: Andrey Vagin , Serge Hallyn , Andrew Vagin , "criu\@openvz.org" , Linux API , Linux Containers , LKML , James Bottomley , linux-fsdevel , Alexander Viro References: <1468520419-28220-1-git-send-email-avagin@openvz.org> <20160721210650.GA10989@outlook.office365.com> <1515f5f2-5a49-fcab-61f4-8b627d3ba3e2@gmail.com> Date: Mon, 25 Jul 2016 08:18:42 -0500 In-Reply-To: (Michael Kerrisk's message of "Mon, 25 Jul 2016 13:47:51 +0200") Message-ID: <87lh0pg8jx.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=1bRfyv-0005N5-73;;;mid=<87lh0pg8jx.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/I/pOVMC5oUKgbM20brzAfl9c3j9Up9oE= 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 * 1.5 XMNoVowels Alpha-numberic number with no vowels * 0.7 XMSubLong Long Subject * 0.0 TVD_RCVD_IP Message was received from an IP address * 1.2 LotsOfNums_01 BODY: Lots of long strings of numbers * 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.4997] * -0.0 DCC_CHECK_NEGATIVE Not listed in DCC * [sa07 1397; Body=1 Fuz1=1 Fuz2=1] X-Spam-DCC: XMission; sa07 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: ***;"Michael Kerrisk \(man-pages\)" X-Spam-Relay-Country: X-Spam-Timing: total 817 ms - load_scoreonly_sql: 0.05 (0.0%), signal_user_changed: 6 (0.8%), b_tie_ro: 5 (0.6%), parse: 1.04 (0.1%), extract_message_metadata: 5 (0.6%), get_uri_detail_list: 3.3 (0.4%), tests_pri_-1000: 4.3 (0.5%), tests_pri_-950: 1.29 (0.2%), tests_pri_-900: 1.06 (0.1%), tests_pri_-400: 36 (4.4%), check_bayes: 35 (4.2%), b_tokenize: 10 (1.3%), b_tok_get_all: 12 (1.5%), b_comp_prob: 3.5 (0.4%), b_tok_touch_all: 4.0 (0.5%), b_finish: 0.80 (0.1%), tests_pri_0: 748 (91.5%), check_dkim_signature: 0.63 (0.1%), check_dkim_adsp: 4.6 (0.6%), tests_pri_500: 3.7 (0.5%), rewrite_mail: 0.00 (0.0%) Subject: Re: [PATCH 0/5 RFC] Add an interface to discover relationships between 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 "Michael Kerrisk (man-pages)" writes: > Hi Andrey, > > On 07/22/2016 08:25 PM, Andrey Vagin wrote: >> On Thu, Jul 21, 2016 at 11:48 PM, Michael Kerrisk (man-pages) >> wrote: >>> Hi Andrey, >>> >>> >>> On 07/21/2016 11:06 PM, Andrew Vagin wrote: >>>> >>>> On Thu, Jul 21, 2016 at 04:41:12PM +0200, Michael Kerrisk (man-pages) >>>> wrote: >>>>> >>>>> Hi Andrey, >>>>> >>>>> On 07/14/2016 08:20 PM, Andrey Vagin wrote: >>>> >>>> >>>> >>>> >>>>> >>>>> Could you add here an of the API in detail: what do these FDs refer to, >>>>> and how do you use them to solve the use case? And could you you add >>>>> that info to the commit messages please. >>>> >>>> >>>> Hi Michael, >>>> >>>> A patch for man-pages is attached. It adds the following text to >>>> namespaces(7). >>>> >>>> Since Linux 4.X, the following ioctl(2) calls are supported for names‐ >>>> pace file descriptors. The correct syntax is: >>>> >>>> fd = ioctl(ns_fd, ioctl_type); >>>> >>>> where ioctl_type is one of the following: >>>> >>>> NS_GET_USERNS >>>> Returns a file descriptor that refers to an owning user names‐ >>>> pace. >>>> >>>> NS_GET_PARENT >>>> Returns a file descriptor that refers to a parent namespace. >>>> This ioctl(2) can be used for pid and user namespaces. For user >>>> namespaces, NS_GET_PARENT and NS_GET_USERNS have the same mean‐ >>>> ing. > > For each of the above, I think it is worth mentioning that the > close-on-exec flag is set for the returned file descriptor. Hmm. That is an odd default. >>>> >>>> In addition to generic ioctl(2) errors, the following specific ones can >>>> occur: >>>> >>>> EINVAL NS_GET_PARENT was called for a nonhierarchical namespace. >>>> >>>> EPERM The requested namespace is outside of the current namespace >>>> scope. > > Perhaps add "and the caller does not have CAP_SYS_ADMIN" in the initial > user namespace"? Having looked at that bit of code I don't think capabilities really have a role to play. >>>> ENOENT ns_fd refers to the init namespace. >>> >>> >>> Thanks for this. But still part of the question remains unanswered. >>> How do we (in user-space) use the file descriptors to answer any of >>> the questions that this patch series was designed to solve? (This >>> info should be in the commit message and the man-pages patch.) >> >> I'm sorry, but I am not sure that I understand what you ask. >> >> Here are the origin questions: >> Someone else then asked me a question that led me to wonder about >> generally introspecting on the parental relationships between user >> namespaces and the association of other namespaces types with user >> namespaces. One use would be visualization, in order to understand the >> running system. Another would be to answer the question I already >> mentioned: what capability does process X have to perform operations >> on a resource governed by namespace Y? >> >> Here is an example which shows how we can get the owning namespace >> inode number by using these ioctl-s. >> >> $ ls -l /proc/13929/ns/pid >> lrwxrwxrwx 1 root root 0 Jul 22 21:03 /proc/13929/ns/pid -> 'pid:[4026532228]' >> >> $ ./nsowner /proc/13929/ns/pid >> user:[4026532227] >> >> The owning user namespace for pid:[4026532228] is user:[4026532227]. >> >> The nsowner tool is cimpiled from this code: >> >> int main(int argc, char *argv[]) >> { >> char buf[128], path[] = "/proc/self/fd/0123456789"; >> int ns, uns, ret; >> >> ns = open(argv[1], O_RDONLY); >> if (ns < 0) >> return 1; >> >> uns = ioctl(ns, NS_GET_USERNS); >> if (uns < 0) >> return 1; >> >> snprintf(path, sizeof(path), "/proc/self/fd/%d", uns); >> ret = readlink(path, buf, sizeof(buf) - 1); >> if (ret < 0) >> return 1; >> buf[ret] = 0; >> >> printf("%s\n", buf); >> >> return 0; >> } > > So, from my point of view, the important piece that was missing from > your commit message was the note to use readlink("/proc/self/fd/%d") > on the returned FDs. I think that detail needs to be part of the > commit message (and also the man page text). I think it even be > helpful to include the above program as part of the commit message: > it helps people more quickly grasp the API. Please, please make the standard way to compare these things fstat. That is much less magic than a symlink, and a little more future proof. Possibly even kcmp. At some point we will care about migrating a migrating sub-container and we may have to have some minor changes. Eric