lkml.org 
[lkml]   [2019]   [Apr]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [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

    \
     
     \ /
      Last update: 2019-04-01 23:31    [W:3.095 / U:0.444 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site