Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp4675424imu; Mon, 12 Nov 2018 15:15:30 -0800 (PST) X-Google-Smtp-Source: AJdET5f4ahxsRhW0hF/qj3oJn4FP+ru96ca5m6RlnNsi9VibvJJ/m+BhZ7Viz9q80tr2mvJmgCbe X-Received: by 2002:a17:902:7c0a:: with SMTP id x10-v6mr2746139pll.263.1542064530811; Mon, 12 Nov 2018 15:15:30 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1542064530; cv=none; d=google.com; s=arc-20160816; b=Z85rRyeYSda5XDXzNyOQcTZyMZosT09fF3t5MLJHG8kQpgmTOlXcn/Pf5c/gAEtJt2 6pSpHXsuYUIweW1u37LPxw0IM03F1DTo0EB0ED1R/G1tuPhI6R6TxQPCrvcTO++MGZ3f 72xJQC3r8kqWA2WfKhZoocQNfLfnM+ZnPBh8NPLNnpnQmjd+00kiZfY5YjcZafDAiZor v7EFD57zH2e+K69nF/qMGOzOaHl6tV8cPNE1nrU+YhwTk7z3Tlf7jzvAxBHL4DDaXI1U +xnaTHpqlGM83XS8jYe9vhMw8NJO8/3VJnhYvd8dBBgmer2QIN2BzMJmcObUoFHJa0YU 1Z1Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=Bk6sSlLm/9+7x0N6nQHPRmV8uti8Y2Qe34RQ9ufSLxk=; b=RMEqnHMKCV+KnUWTEU7RH2IESWd8orxD7ln7AaPMmcLnrkHwdupmxSLkRjRHUG0QT9 0AbIglQZhpv+jnh1gPutXoBAQFTNojEunnSZmvlq3tyjj6JxY8mAsYcSbUpOKyFRJZ30 lH3opyON8lUzn1MPvT6eJV2i5ZCjaUsf6IbqmBOYzaLVKTO5HKAbd1MB+2VQ/JwPbrUY iLgQQMbjYpwTaUJ/cU3nVBovpm134mRdMaXLrWIt7E3kciYUh3ykAbx7mezatKXddo09 iLMJVwdLXG6hv43irZdFqIjFOB54fVuHVMdy6lUBONBfBuSxeZ/+v8aoLoxVfTI/45Uq oUog== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id c4si3801712pll.412.2018.11.12.15.15.14; Mon, 12 Nov 2018 15:15:30 -0800 (PST) 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; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729443AbeKMJI5 (ORCPT + 99 others); Tue, 13 Nov 2018 04:08:57 -0500 Received: from atrey.karlin.mff.cuni.cz ([195.113.26.193]:60864 "EHLO atrey.karlin.mff.cuni.cz" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726078AbeKMJI5 (ORCPT ); Tue, 13 Nov 2018 04:08:57 -0500 Received: by atrey.karlin.mff.cuni.cz (Postfix, from userid 512) id A694D80707; Tue, 13 Nov 2018 00:13:34 +0100 (CET) Date: Tue, 13 Nov 2018 00:13:36 +0100 From: Pavel Machek To: Daniel Colascione Cc: linux-kernel@vger.kernel.org, timmurray@google.com, joelaf@google.com, surenb@google.com Subject: Re: [RFC PATCH] Implement /proc/pid/kill Message-ID: <20181112231336.GA19782@amd> References: <20181029221037.87724-1-dancol@google.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="2fHTh5uZTiUOsy+g" Content-Disposition: inline In-Reply-To: <20181029221037.87724-1-dancol@google.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --2fHTh5uZTiUOsy+g Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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'. >=20 > 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 --=20 (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blo= g.html --2fHTh5uZTiUOsy+g Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlvqCSAACgkQMOfwapXb+vIo3gCdEmoJndbQ+y+GOcPqUKHUGyph P8gAoMSRdCx9YsYEsnRJtD701eG8m+QQ =xYQD -----END PGP SIGNATURE----- --2fHTh5uZTiUOsy+g--