On 2018-10-29, Daniel Colascione 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