Messages in this thread | | | From | Linus Torvalds <> | Date | Mon, 1 Apr 2019 14:30:19 -0700 | Subject | Re: [PATCH v2 0/5] pid: add pidfd_open() |
| |
On Mon, Apr 1, 2019 at 12:42 PM Christian Brauner <christian@brauner.io> wrote: > > From what I gather from this thread we are still best of with using fds > to /proc/<pid> as pidfds. Linus, do you agree or have I misunderstood?
That does seem to be the most flexible option.
> Yes, we can have an internal mount option to restrict access to various > parts of procfs from such pidfds
I suspect you'd find that other parties might want such a "restrict proc" mount option too, so I don't think it needs to be anything internal.
But it would be pretty much independent of the pidfd issue, of course.
> One thing is that we also need something to disable access to the > "/proc/<pid>/net". One option could be to give the files in "net/" an > ->open-handler which checks that our file->f_path.mnt is not one of our > special clone() mounts and if it is refuse the open.
I would expect that that would be part of the "restrict proc" mount options, no?
> Basically, if you have a system without CONFIG_PROC_FS it makes sense > that clone gives back an anon inode file descriptor as pidfds because > you can still signal threads in a race-free way. But it doesn't make a > lot of sense to have pidfd_open() in this scenario because you can't > really do anything with that pidfd apart from sending signals.
Well, people might want that.
But realistically, everybody enables /proc support anyway. Even if you don't actually fully *mount* it in some restricted area, the support is pretty much always there in any kernel config.
But yes, in general I agree that that also most likely means that a separate system call for "open_pidfd()" isn't worth it.
Because if the main objection to /proc is that it exposes too much, then I think a much better option is to see how to sanely restrict the "too much" parts.
Because I think there might be a lot of people who want a restricted /proc, in various container models etc.
Linus
| |