From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.4 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_IN_DEF_DKIM_WL autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id E6464C47404 for ; Fri, 11 Oct 2019 18:21:09 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id B54AD20673 for ; Fri, 11 Oct 2019 18:21:09 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="IvMSiekA" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728880AbfJKSVI (ORCPT ); Fri, 11 Oct 2019 14:21:08 -0400 Received: from mail-ot1-f67.google.com ([209.85.210.67]:40803 "EHLO mail-ot1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728666AbfJKSVI (ORCPT ); Fri, 11 Oct 2019 14:21:08 -0400 Received: by mail-ot1-f67.google.com with SMTP id y39so8763143ota.7 for ; Fri, 11 Oct 2019 11:21:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=NzPNFjQAnsNKPF9to6rHis9Bc+uXElpyCzjzqc3xUoA=; b=IvMSiekARullkWXq/ftFjAcZMOjhvs+6/3a4OtqHQasin2qPvykrRKbGv9Usd7sy12 ulb1mILf15cAPtN3I1Lbzb5DoSzaj4lLXvjYOXl+AFJJFvuStN5KhZz958qQCHlX7mlK VzHJuU70gtQqiB3R6rIak9sy8QzqKM0ZqN+BCeDpDj0EbFbKWeSIaBU13d0ph7rPOpDu L+3GRaUTlBevjN29xui9vM2NZnUIvEgM01iz5UGGj7gdV/in5n/l7L23RrV0Xr5Sn/8j UqEkK4i8d6pyYcxEedHJ9Pl5viAr8XW64yXzmgQzO7iMzWXg9tCcbpaVCdLOYR3E7YjK tQxA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=NzPNFjQAnsNKPF9to6rHis9Bc+uXElpyCzjzqc3xUoA=; b=D6lqKZF1/yLsYUjkdQwxOYUpiNjTontWPTVk+sNmMOjvcuiexMHKUAEPQ3jBAD733S HQhISkg6kNfw8/rH2RFF6mChA8IGZ88D7azQzZBK1qulqjFm5ppB9AEAWUhy/OtMwq14 ILkEcVOCIb7pVoCD2/Z0ZTTK/+6Ri6uTFSVuENDvMJmOdqUspDdIkcSyUufnsy98eixr pnSlDI7lxJi4npAqUhBMjMIqoh5llIG2SG6qAjtDkvgCCNelg0EtZdlC4vNa0EaFs47v 0sjAF/s9kiIyZnlTQXiSwtlq2V04bY3xkTd+yaKSqC+FCTpMSgCcdRDVXo4OCiF0BCST z15w== X-Gm-Message-State: APjAAAVDMIjEO4IRk6Jrf9H4xXqtn10321/mYxyMk42HSRKk7SCi3K3r 70H7P5nE8KP7cgMgEnUcG0owqu0BOm9BxAy/I5KziQ== X-Google-Smtp-Source: APXvYqzdnyAgT/2B3EV+6PwhAKTjGeyVIet5s9sy4vmnfPUelbIpY/41Ijbdobh8yEQZadta3Qs7UMppdkBOA/JYl94= X-Received: by 2002:a05:6830:10cc:: with SMTP id z12mr6088889oto.110.1570818066578; Fri, 11 Oct 2019 11:21:06 -0700 (PDT) MIME-Version: 1.0 References: <20191009160532.20674-1-ckellner@redhat.com> <20191011122323.7770-1-ckellner@redhat.com> <20191011151700.hdvztoxonpvogadv@wittgenstein> <20191011165851.gf5i6qw2fwbunshr@wittgenstein> In-Reply-To: <20191011165851.gf5i6qw2fwbunshr@wittgenstein> From: Jann Horn Date: Fri, 11 Oct 2019 20:20:39 +0200 Message-ID: Subject: Re: [PATCH v3 1/2] pidfd: show pids for nested pid namespaces in fdinfo To: Christian Brauner Cc: Christian Kellner , kernel list , Linux API , Christian Kellner , Andrew Morton , "Peter Zijlstra (Intel)" , Ingo Molnar , Michal Hocko , Thomas Gleixner , Elena Reshetova , Roman Gushchin , Andrea Arcangeli , Al Viro , Aleksa Sarai , "Dmitry V. Levin" Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Oct 11, 2019 at 6:58 PM Christian Brauner wrote: > On Fri, Oct 11, 2019 at 05:30:03PM +0200, Jann Horn wrote: > > On Fri, Oct 11, 2019 at 5:17 PM Christian Brauner > > wrote: > > > > > > On Fri, Oct 11, 2019 at 04:55:59PM +0200, Jann Horn wrote: > > > > On Fri, Oct 11, 2019 at 2:23 PM Christian Kellner wrote: > > > > > The fdinfo file for a process file descriptor already contains the > > > > > pid of the process in the callers namespaces. Additionally, if pid > > > > > namespaces are configured, show the process ids of the process in > > > > > all nested namespaces in the same format as in the procfs status > > > > > file, i.e. "NSPid:\t%d\%d...". This allows the easy identification > > > > > of the processes in nested namespaces. > > > > [...] > > > > > #ifdef CONFIG_PROC_FS > > > > > +static inline void print_pidfd_nspid(struct seq_file *m, struct pid *pid, > > > > > + struct pid_namespace *ns) > > > > > > > > `ns` is the namespace of the PID namespace of the procfs instance > > > > through which the file descriptor is being viewed. > > > > > > > > > +{ > > > > > +#ifdef CONFIG_PID_NS > > > > > + int i; > > > > > + > > > > > + seq_puts(m, "\nNSpid:"); > > > > > + for (i = ns->level; i <= pid->level; i++) { > > > > > > > > ns->level is the level of the PID namespace associated with the procfs > > > > instance through which the file descriptor is being viewed. pid->level > > > > is the level of the PID associated with the pidfd. > > > > > > > > > + ns = pid->numbers[i].ns; > > > > > + seq_put_decimal_ull(m, "\t", pid_nr_ns(pid, ns)); > > > > > + } > > > > > +#endif > > > > > +} > > > > > > > > I think you assumed that `ns` is always going to contain `pid`. > > > > However, that's not the case. Consider the following scenario: > > > > > > > > - the init_pid_ns has two child PID namespaces, A and B (each with > > > > its own mount namespace and procfs instance) > > > > - process P1 lives in A > > > > - process P2 lives in B > > > > - P1 opens a pidfd for itself > > > > - P1 passes the pidfd to P2 (e.g. via a unix domain socket) > > > > - P2 reads /proc/self/fdinfo/$pidfd > > > > > > > > Now the loop will print the ID of P1 in A. I don't think that's what > > > > you intended? You might want to bail out if "pid_nr_ns(pid, ns) == 0", > > > > or something like that. > > > > > > I assumed the same thing happens when you pass around an fd for > > > /proc/self/status and that's why I didn't object to this behavior. > > > > I don't see how /proc/$pid/status is relevant. In the > > /proc/$pid/status case, the output is the list of PIDs starting at the > > PID namespace the procfs is associated with; and the process is always > > contained in that namespace, which also means that the first PID > > listed is the one in the PID namespace of the procfs instance. In the > > pidfd case, the process is not necessarily contained in that > > namespace, and the output doesn't make sense. > > I might be misreading what you're saying. > (Maybe I'm doing something obviously wrong.) > If I compile the following two programs: > b2: https://paste.ubuntu.com/p/xthMsCXy3s/ > c2: https://paste.ubuntu.com/p/y5HSzyMQJr/ > > Then in shell1 > sudo unshare --mount --pid --fork --mount-proc > > and in shell2 > sudo unshare --mount --pid --fork --mount-proc > > and run b2 in shell1 and c2 in shell2 which sends around an fd for > /proc/b2/status to c2. Now c2 reads b2's status file via the fd it > received. The c2 will see the pid of b2 in b2's pid namespace even > though the process is not contained in the pid namespace of c2. Because the reader doesn't matter; the perspective you have on the system is defined by which pidns the procfs instance you're looking through is associated with, and here you're looking through shell1's procfs. It's normal that when you look through another procfs, you see PIDs differently.