lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200618091857.atycw6ioaiuhddmj@wittgenstein>
Date:   Thu, 18 Jun 2020 11:18:57 +0200
From:   Christian Brauner <christian.brauner@...ntu.com>
To:     "Michael Kerrisk (man-pages)" <mtk.manpages@...il.com>
Cc:     "linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>,
        lkml <linux-kernel@...r.kernel.org>,
        Wolfgang Bumiller <w.bumiller@...xmox.com>,
        Serge Hallyn <serge@...lyn.com>,
        Alexander Viro <viro@...iv.linux.org.uk>
Subject: Re: [PATCH] nsfs: add NS_GET_INIT_PID ioctl

On Thu, Jun 18, 2020 at 11:03:25AM +0200, Michael Kerrisk (man-pages) wrote:
> On Thu, 18 Jun 2020 at 10:45, Christian Brauner
> <christian.brauner@...ntu.com> wrote:
> >
> > Add an ioctl() to return the PID of the init process/child reaper of a pid
> > namespace as seen in the caller's pid namespace.
> 
> What are the pros and cons of returning a PID FD instead of a PID?

A pidfd doesn't buy you much here since you can race-free turn the PID
into a pidfd via pidfd_open() right after.
But mostly, I don't want to introduce the pattern of returning pidfds
from all corners of the kernel especially when it's not strictly
required. The central entrypoints should remain clone{3}() and
pidfd_open() for now. I want to remain conservative with this until we
have had more of userspace rely on them for a while and the bugs and
features requests come trickling in. We've seen a good portion of that
but we'll likely see more. If we need to do global changes (e.g. sending
signals outside of your own pid namespace hierarchy or attaching
capabilities to them) we will be in better shape if we don't return them
from everywhere just yet.

Christian

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ