[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20181112231336.GA19782@amd>
Date: Tue, 13 Nov 2018 00:13:36 +0100
From: Pavel Machek <pavel@....cz>
To: Daniel Colascione <dancol@...gle.com>
Cc: linux-kernel@...r.kernel.org, timmurray@...gle.com,
joelaf@...gle.com, surenb@...gle.com
Subject: Re: [RFC PATCH] Implement /proc/pid/kill
Hi!
> 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.
I'd really prefer this to use a new syscall, taking directory fd as an
argument. Various security solutions (seccomp, chromium sandbox,
ptrace/subterfugue) could be pretty surprised what write to a file is
doing...
> 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".
Actually.. if you open /proc/123 directory, is pid 123 still going to
be reused?
If so... could we simply block reuse of that pid as long as directory
is open? It would solve the race w/o new file and w/o new syscall...
Good luck,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Download attachment "signature.asc" of type "application/pgp-signature" (182 bytes)
Powered by blists - more mailing lists