Messages in this thread | | | Date | Tue, 30 Oct 2018 16:00:12 +1100 | From | Aleksa Sarai <> | Subject | Re: [RFC PATCH] Implement /proc/pid/kill |
| |
On 2018-10-29, Daniel Colascione <dancol@google.com> wrote: > Add a simple proc-based kill interface. To use /proc/pid/kill, just > write the signal number in base-10 ASCII to the kill file of the > process to be killed: for example, 'echo 9 > /proc/$$/kill'. > > Semantically, /proc/pid/kill works like kill(2), except that the > process ID comes from the proc filesystem context instead of from an > explicit system call parameter. This way, it's possible to avoid races > between inspecting some aspect of a process and that process's PID > being reused for some other process.
(Aside from any UX concerns other folks might have.)
I think it would be a good idea to (at least temporarily) restrict this so that only processes that are in the same PID namespace as the /proc being resolved through may use this interface. Otherwise you might have cases where partial container breakouts can start sending signals to PIDs they wouldn't normally be able to address.
> With /proc/pid/kill, it's possible to write a proper race-free and > safe pkill(1). An approximation follows. A real program might use > openat(2), having opened a process's /proc/pid directory explicitly, > with the directory file descriptor serving as a sort of "process > handle".
I do like the idea of holding a dirfd to /proc/$pid to address processes, and it something I considered doing in runc. (Unfortunately there are lots of things that make it a bit difficult to use /proc/$pid exclusively for introspection of a process -- especially in the context of containers.)
-- Aleksa Sarai Senior Software Engineer (Containers) SUSE Linux GmbH <https://www.cyphar.com/> [unhandled content-type:application/pgp-signature] | |