[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAG48ez0KeQU32HV8OGY4-LNPF0Q+PtaH7H47GmKAd1Hhho=jXw@mail.gmail.com>
Date: Mon, 1 Apr 2019 15:43:13 +0200
From: Jann Horn <jannh@...gle.com>
To: Christian Brauner <christian@...uner.io>,
Al Viro <viro@...iv.linux.org.uk>,
Andy Lutomirski <luto@...capital.net>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
Daniel Colascione <dancol@...gle.com>,
Andrew Lutomirski <luto@...nel.org>,
David Howells <dhowells@...hat.com>,
"Serge E. Hallyn" <serge@...lyn.com>,
Linux API <linux-api@...r.kernel.org>,
Linux List Kernel Mailing <linux-kernel@...r.kernel.org>,
Arnd Bergmann <arnd@...db.de>,
"Eric W. Biederman" <ebiederm@...ssion.com>,
Konstantin Khlebnikov <khlebnikov@...dex-team.ru>,
Kees Cook <keescook@...omium.org>,
Alexey Dobriyan <adobriyan@...il.com>,
Thomas Gleixner <tglx@...utronix.de>,
Michael Kerrisk-manpages <mtk.manpages@...il.com>,
Jonathan Kowalski <bl0pbl33p@...il.com>,
"Dmitry V. Levin" <ldv@...linux.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Oleg Nesterov <oleg@...hat.com>,
Nagarathnam Muthusamy <nagarathnam.muthusamy@...cle.com>,
Aleksa Sarai <cyphar@...har.com>,
Joel Fernandes <joel@...lfernandes.org>
Subject: Re: [PATCH v2 0/5] pid: add pidfd_open()
On Mon, Apr 1, 2019 at 2:04 PM Christian Brauner <christian@...uner.io> wrote:
> On Sun, Mar 31, 2019 at 08:13:38PM -0600, Andy Lutomirski wrote:
> > > On Mar 31, 2019, at 3:17 PM, Linus Torvalds <torvalds@...ux-foundation.org> wrote:
> > >> On Sun, Mar 31, 2019 at 2:10 PM Christian Brauner <christian@...uner.io> wrote:
> > >>
> > >> I don't think that we want or can make them equivalent since that would
> > >> mean we depend on procfs.
> > >
> > > Sure we can.
> > >
> > > If /proc is enabled, then you always do that dance YOU ALREADY WROTE
> > > THE CODE FOR to do the stupid ioctl.
> > >
> > > And if /procfs isn't enabled, then you don't do that.
> > >
> > > Ta-daa. Done. No stupid ioctl, and now /proc and pidfd_open() return
> > > the same damn thing.
> > >
> > > And guess what? If /proc isn't enabled, then obviously pidfd_open()
> > > gives you the /proc-less thing, but at least there is no crazy "two
> > > different file descriptors for the same thing" situation, because then
> > > the /proc one doesn't exist.
> > >
> >
> > I wish we could do this, and, in a clean design, it would be a no-brainer. But /proc has too much baggage. Just to mention two such things, there’s “net” and “../sys”. This crud is why we have all kinds of crazy rules that prevent programs in sandboxes from making a new mounts and mounting /proc in it. If we make it possible to clone a new process and this access /proc without having /proc mounted, we’ll open up a big can of worms.
> >
> > Maybe we could have a sanitized view of /proc and make a pidfd be a directory fd pointing at that.
>
> We can also just create something like an internal bind-mount without a
> parent, i.e. similar to
>
> open_tree(<internal-procfs-mount>, "<pid>", OPEN_TREE_CLONE);
>
> on a clone(CLONE_PIDFD);
>
> that would block any openat(fd, "..");
Or we add a check to follow_dotdot()/follow_dotdot_rcu() that throws
an error if nd->path.mnt->mnt_flags has some new flag for "no dotdot
traversal on this mountpoint", and then set that on the internal procfs
mount... if Al Viro doesn't think that that's too hideous.
Powered by blists - more mailing lists