New system calls: pidfd_open() and close_range()

Posted May 23, 2019 23:40 UTC (Thu) by cyphar (subscriber, #110703)
In reply to: New system calls: pidfd_open() and close_range() by ju3Ceemi
Parent article: New system calls: pidfd_open() and close_range()

You can already do this by looping over /proc/self/fd. This is what rpm, zypper, and quite a few other programs do.

to post comments

New system calls: pidfd_open() and close_range()

Posted May 24, 2019 17:27 UTC (Fri) by ju3Ceemi (subscriber, #102464) [Link] (6 responses)

Sure, but one needs access to the procfs, which is the issue

New system calls: pidfd_open() and close_range()

Posted May 25, 2019 23:06 UTC (Sat) by quotemstr (subscriber, #45331) [Link] (5 responses)

No, it isn't the issue at all. We shouldn't optimize the kernel for random important kernel interfaces being disabled. Why should running without procfs be a supported configuration at all? Why are we even spending time on this bizarre usecase? We should just hardcode CONFIG_PROCFS=y.

New system calls: pidfd_open() and close_range()

Posted May 25, 2019 23:21 UTC (Sat) by mpr22 (subscriber, #60784) [Link] (4 responses)

Just because /proc is mounted doesn't mean that all the processes on the system have a view of the fs hierarchy that lets them see it.

New system calls: pidfd_open() and close_range()

Posted May 25, 2019 23:31 UTC (Sat) by quotemstr (subscriber, #45331) [Link] (3 responses)

That's true, but the right approach here is to make a useful subset of /proc visible to all processes regardless of the mount table instead of adding dedicated system calls that reproduce what /proc can already do just for those rare cases where /proc isn't available.

New system calls: pidfd_open() and close_range()

Posted May 26, 2019 20:46 UTC (Sun) by roc (subscriber, #30627) [Link] (2 responses)

Mount namespaces and filesystem path resolution are already complicated enough without adding new "always visible" mounts.

Maybe a single new form of "open" syscall that opts into a different mount namespace that contains /proc and nothing else?

New system calls: pidfd_open() and close_range()

Posted May 26, 2019 20:52 UTC (Sun) by quotemstr (subscriber, #45331) [Link] (1 responses)

> Maybe a single new form of "open" syscall that opts into a different mount namespace that contains /proc and nothing else?

That's basically what I had in mind. I'm imagining an open_proc(2) that returns a dirfd that can be used to access standard procfs files using openat(2), with the specific filesystem returned by open_proc(2) filtered to restrict access to security-sensitive parts of procfs like /proc/pid/net.

But I got a ton of opposition on lkml when I proposed something like this, so I think that my always-available procfs idea will be in the far future. :-(

New system calls: pidfd_open() and close_range()

Posted May 28, 2019 16:21 UTC (Tue) by nybble41 (subscriber, #55106) [Link]

> I'm imagining an open_proc(2) that returns a dirfd that can be used to access standard procfs files using openat(2) ...

If the pidfd_open() syscall is added, would it be possible to use the returned pidfd with openat()? My understanding is that the result should be equivalent to calling open("/proc/PID") in a context where /proc is procfs, whether or not /proc is visibly mounted. That would offer access to at least the standard /proc/PID hierarchy regardless of mount namespaces or other factors affecting path resolution.

New system calls: pidfd_open() and close_range()

Posted Jul 24, 2019 22:52 UTC (Wed) by immibis (subscriber, #105511) [Link]

There's also the case where you have too many file descriptors open already, and shouldn't have to open one more in order to close some.