Re: [RFC PATCH] Implement /proc/pid/kill

[Daniel Colascione]

On Tue, Oct 30, 2018 at 5:00 AM, Aleksa Sarai <cyphar@xxxxxxxxxx> wrote:
> On 2018-10-29, Daniel Colascione <dancol@xxxxxxxxxx> 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?