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

On Sun, Nov 18, 2018 at 8:33 AM, Randy Dunlap [off-list ref] wrote:

On 11/18/18 8:17 AM, Andy Lutomirski 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.

quoted

quoted

I have an old patch to make proc directory fds pollable:

https://lore.kernel.org/patchwork/patch/345098/

That patch plus the one in this thread might make a nice addition to
the kernel even if we expect something much better to come along
later.

I've always commented on that patch. You never addressed my technical
objections. Why are you bringing up this patch again as if that
discussion had never happened? To review, that patch has various race
conditions

I don't think I ever saw that review.

quoted

and even if it were technically correct, it'd be an abuse
of directory objects (in what other circumstance do we poll
directories?) and not logically generalizable to a model in which we
expose process exit status via the exit-monitoring API.

I agree it's weird.  It might be better to have /proc/PID/exit_status
and make *that* pollable.

If there is a new exit_status file, it could even be more than
8 bits of exit status:

See https://lore.kernel.org/lkml/alpine.LSU.2.20.1507091257010.9602@nerf40.vanv.qr/T/#u (local)
and http://austingroupbugs.net/view.php?id=594#c1317

First of all, as I discussed in [1], we need to first figure out *who*
should have access to the process exit information. FreeBSD appears to
make it public without disaster, and if we make exit status public, a
lot of problems just disappear.

[1] https://lore.kernel.org/lkml/CAKOZueussVwABQaC+O9fW+MZayccvttKQZfWg0hh-cZ+1ykXig@mail.gmail.com/ (local)

Providing more than eight bits of status information is a separate
discussion. I don't think it's necessary, since it breaks assumptions
people make today without really adding much in the way of new
capabilities. If we want to let processes die while leaving behind
more information, let's let them leave behind an arbitrary-sized
string or something instead of repeating the mistake of an integral
exit status, but with more bits.