Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
In-Reply-To: <20181030050012.u43lcvydy6nom3ul@yavin>
References: <20181029221037.87724-1-dancol@google.com> <20181030050012.u43lcvydy6nom3ul@yavin>
From:   Daniel Colascione <dancol@google.com>
Date:   Tue, 30 Oct 2018 09:05:20 +0000
Message-ID: <CAKOZuesKVic-5epRj8XcFNR_63SgvaPcbjDQuSLxNrEfS=O=Jg@mail.gmail.com>
Subject: Re: [RFC PATCH] Implement /proc/pid/kill
To:     Aleksa Sarai <cyphar@cyphar.com>
Cc:     linux-kernel <linux-kernel@vger.kernel.org>,
        Tim Murray <timmurray@google.com>,
        Joel Fernandes <joelaf@google.com>,
        Suren Baghdasaryan <surenb@google.com>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Tue, Oct 30, 2018 at 5:00 AM, Aleksa Sarai <cyphar@cyphar.com> wrote:
> 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.

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?