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: <061df748f65d41b5bbd4749074dbce29@AcuMS.aculab.com>
References: <20181029221037.87724-1-dancol@google.com> <87bm7a3et9.fsf@xmission.com>
 <20181031124435.GA9007@redhat.com> <CAKOZuevTF2cjJ0-nK7nv7jbgFexyW-deScaYVzE3iEPC48SAJg@mail.gmail.com>
 <061df748f65d41b5bbd4749074dbce29@AcuMS.aculab.com>
From:   Daniel Colascione <dancol@google.com>
Date:   Thu, 1 Nov 2018 15:50:20 +0000
Message-ID: <CAKOZueuRbYh5dKoT4R6_t87yKZR_bzX+7s4KevvSmfcBk+YeYw@mail.gmail.com>
Subject: Re: [RFC PATCH] Implement /proc/pid/kill
To:     David Laight <David.Laight@aculab.com>
Cc:     Oleg Nesterov <oleg@redhat.com>,
        "Eric W. Biederman" <ebiederm@xmission.com>,
        linux-kernel <linux-kernel@vger.kernel.org>,
        Tim Murray <timmurray@google.com>,
        Joel Fernandes <joelaf@google.com>,
        Suren Baghdasaryan <surenb@google.com>,
        Kees Cook <keescook@chromium.org>,
        Christian Brauner <christian.brauner@canonical.com>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Thu, Nov 1, 2018 at 11:53 AM, David Laight <David.Laight@aculab.com> wrote:
> From: Sent: 31 October 2018 13:28
> ...
>> * I actually have a local variant of the patch that would have you
>> open "/proc/$PID/kill/$SIGNO" instead, since different signal numbers
>> have different permission checks.
>
> I think you'd need the open() to specify some specific unusual
> open modes.
> Otherwise it'll be far too easy for scripts (and people) to
> accidentally send every signal to every process.

I think the /proc/$PID/kill/$SIGNO idea is dead anyway, and even
dead-er since Linus banned write() for commands. (Looks like we'll
need a system call after all.)

That said, for the record, I was talking about the *write* sending the
signal, not the open, so grep of /proc wouldn't send random signals to
every process.

> Also think of the memory footprint.

Proc inodes are created on-demand, so AIUI, the memory overhead of
heaving a per-FD directory of stuff isn't very high.