Re: [PATCH] proc: allow killing processes via file descriptors

On Sun, Nov 18, 2018 at 9:13 AM, Andy Lutomirski [off-list ref] wrote:

On Sun, Nov 18, 2018 at 8:29 AM Daniel Colascione [off-list ref] wrote:

quoted

On Sun, Nov 18, 2018 at 8:17 AM, Andy Lutomirski [off-list ref] wrote:

quoted

On Sun, Nov 18, 2018 at 7:53 AM Daniel Colascione [off-list ref] wrote:

quoted

On Sun, Nov 18, 2018 at 7:38 AM, Andy Lutomirski [off-list ref] wrote:

quoted

I fully agree that a more comprehensive, less expensive API for
managing processes would be nice.  But I also think that this patch
(using the directory fd and ioctl) is better from a security
perspective than using a new file in /proc.

That's an assertion, not an argument. And I'm not opposed to an
operation on the directory FD, now that it's clear Linus has banned
"write(2)-as-a-command" APIs. I just insist that we implement the API
with a system call instead of a less-reliable ioctl due to the
inherent namespace collision issues in ioctl command names.

Linus banned it because of bugs iike the ones in the patch.

Maybe: he didn't provide a reason. What's your point?

My point is that an API that involves a file like /proc/PID/kill is
very tricky to get right.  Here are some considerations:

Moot. write(2) for this interface is off the table anyway. The right
approach here is a system call that accepts a /proc/pid directory file
descriptor, a signal number, and a signal information field (as in
sigqueue(2)).

Now if we had an ioctlat() API, maybe it would make sense.  But we
don't, and I think it would be a bit crazy to add one.

A process is not a driver. Why won't this idea of using an ioctl for
the kill-process-by-dfd thing just won't die? An ioctl has *zero*
advantage in this context.