On Mon, Apr 1, 2019 at 12:42 PM Christian Brauner <christian@xxxxxxxxxx> 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
