On Tue, Oct 30, 2018 at 5:00 AM, Aleksa Sarai <cyp...@cyphar.com> wrote: > On 2018-10-29, Daniel Colascione <dan...@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.
That's a good idea. >> 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. I did think about explicit system calls to create userspace struct pid references, independent of proc --- something like open_process(int pid). But when we already have procfs, which is already a way of getting struct pid references, why add a new interface? Granted, not everyone has /proc mounted. One idea add a special PROCFS_FD constant (say, -2) that you would supply to openat(2) as dirfd. When openat(2) saw PROCFS_FD, it'd interpret the open as relative to procfs whether or not /proc were actually mounted anywhere. This facility would let you open a "proc" file from anywhere even without the right mounts set up. > (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.) Tons of things already break without a working /proc. What do you have in mind?
