Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp1967847imu; Sun, 18 Nov 2018 12:42:45 -0800 (PST) X-Google-Smtp-Source: AJdET5cWL1gs9MwsZ8teIaKWE5M6G2u5LL1yOvsfYdLMypQEBlEEVRs+0wJhsCQ0wZ4eCSSHA6Jk X-Received: by 2002:a63:d655:: with SMTP id d21mr17630099pgj.280.1542573765191; Sun, 18 Nov 2018 12:42:45 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1542573765; cv=none; d=google.com; s=arc-20160816; b=ptWi6Qxsga45OUTrYIS6TvOAdZ6d+GF0qbuJyoSLgYU6TaA9wVnYGXjShgWRMM7gRN kBCfksLZ+gS4s4+Xu/o3eVICIBEanLej20R2tcjzdBk0rN+F/xXAe70zsPnTyhuikAfM 0YDEdrICrg8WKWzrMXn0HNNHPDS2OsIKF0+WIeTvttfuyINx9kGV17BSTWZeSYi5rjdD ZPqy2NFtcHkOBZpAhzWRTVtMsCfXDWUegCoH4CoegzOsW//25ralZa0ixG6Ds8Jybd8o 7UWXIPrgOLojBZMbyHP8CO6UzUw+sjnzEhAg7uUlSn5n2uH/V9iAJJPOG4HYU83Y85zQ K+9w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:cc:to:subject :message-id:date:from:references:in-reply-to:mime-version :dkim-signature; bh=en+J5RAKD8cLkaXfMXEkLrR1SyaamgkVqtyoR4X0bDY=; b=y3dO47mNZlpmeLFLU3tE4JczJBQOQw5dLKSu8zCg0MhuBBsKiC6i7ZHcLrwIikiQw/ Bn1//bPnEahwQy1XFT+LAwBnoyBx2K90ulcAUysaTHHtGIvZL9MqQ9R4bKbQjqH6Ivg4 s+UwuizRAn0fR7RCdYyPflrXzDWMBV77rjKvKh4UcMXgFF4lHt/l+fU5X9JiN4bnHYPm NTi/8u/EectC2h97egnkWONaVcuV4ZASAn3J47f4++kfcxJa8lyqsZFVed6dlmSUdElj KHyAvnBpgAqkdVxuBHy58gaKiIXot24r/ukVRcmokXDtsjU7OeU4DHzRrV3NPAOUuwj3 l++w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=DVK0+TfW; 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; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id y63si7457148pfg.194.2018.11.18.12.42.18; Sun, 18 Nov 2018 12:42:45 -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; dkim=pass header.i=@google.com header.s=20161025 header.b=DVK0+TfW; 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; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726995AbeKSGyP (ORCPT + 99 others); Mon, 19 Nov 2018 01:54:15 -0500 Received: from mail-vs1-f68.google.com ([209.85.217.68]:40603 "EHLO mail-vs1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725978AbeKSGyP (ORCPT ); Mon, 19 Nov 2018 01:54:15 -0500 Received: by mail-vs1-f68.google.com with SMTP id z3so766384vsf.7 for ; Sun, 18 Nov 2018 12:32:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=en+J5RAKD8cLkaXfMXEkLrR1SyaamgkVqtyoR4X0bDY=; b=DVK0+TfW8gWh0sIgUIq390EhQMOilivFqkQZeXG9grpsmLGcFNY/opi/tC/hEoG2/g Lx89y0Ktkb0x15KrkPo0CfldijTqJmeE7imkk26OCZpnfotXCRc3LTPW7ToMggioJObN x0HLJNULxrxiZ9xlOaB2mE01wRaWus505NB6uasQWXni2LyrmGBrmp9xs6F85Dy+xyzG Q0Lf8b4nsnL8SPEQ+Nemhk1PsX5R6ilrTCZjEyGOyEhcFB3MdP9gFjEzx3flR/ykE2PW xNQHV5G/Vt7SyswHvO8W3298Lvnz/5IZmX1TL7xtzRYF9bEd/UuNO3fnDfzeiX0e9iUg qmyA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=en+J5RAKD8cLkaXfMXEkLrR1SyaamgkVqtyoR4X0bDY=; b=qPdiqu34CU4i/JdZz39MInhY2NpvypLI1/dXWORMY3k/cN4H7OgMnJq0fdBE0WAFgy xPynnWWWBsA9LkIaJzRNVUyY1Gkw3NgkjEKwIuzk1XThC9/93k4Ae4WnAw/zV/JRhRok 600BZUr9C7DlKIVAmUcu2CZn3yiyi/OcRh7SHhzJCJ+RITyfx4Y/dXVGb14tf8/yiyAd xMfaWGQQizUV9T5vafNjyDZVfJUE3JU6To5i8YiiuCpOZE3v7NEvE3IjOT9RlhASCxTu GuAw/OSw5LcbdTiR7SRrHuxnLzQl9VBRIf4o58ZjnPdetvIWzcGkV4FpQa4lZD40e3If MG/A== X-Gm-Message-State: AGRZ1gKLJCL1gRqXx1og2I7FttZcQbXLq7IFBIa3piQKen1JjfBCmtw6 5I1n8PrAh7pU3RKxEj6DsjH5pcoI+BGGVHtrt7+/gQ== X-Received: by 2002:a67:b44:: with SMTP id 65mr7961791vsl.77.1542573177603; Sun, 18 Nov 2018 12:32:57 -0800 (PST) MIME-Version: 1.0 Received: by 2002:a67:f48d:0:0:0:0:0 with HTTP; Sun, 18 Nov 2018 12:32:56 -0800 (PST) In-Reply-To: <608F2959-800D-46EE-A7CD-8C972ACD2F02@amacapital.net> References: <20181118190504.ixglsqbn6mxkcdzu@yavin> <608F2959-800D-46EE-A7CD-8C972ACD2F02@amacapital.net> From: Daniel Colascione Date: Sun, 18 Nov 2018 12:32:56 -0800 Message-ID: Subject: Re: [PATCH] proc: allow killing processes via file descriptors To: Andy Lutomirski Cc: Aleksa Sarai , Andy Lutomirski , Randy Dunlap , Christian Brauner , "Eric W. Biederman" , LKML , "Serge E. Hallyn" , Jann Horn , Andrew Morton , Oleg Nesterov , Al Viro , Linux FS Devel , Linux API , Tim Murray , Kees Cook , Jan Engelhardt Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, Nov 18, 2018 at 12:28 PM, Andy Lutomirski wro= te: >> That is, I'm proposing an API that looks like this: >> >> int process_kill(int procfs_dfd, int signo, const union sigval value) >> >> If, later, process_kill were to *also* accept process-capability FDs, >> nothing would break. > > Except that this makes it ambiguous to the caller as to whether their cur= rent creds are considered. So it would need to be a different syscall or a= t least a flag. Otherwise a lot of those nice theoretical properties go aw= ay. Sure. A flag might make for better ergonomics. >> Yes, that's what I have in mind. A siginfo_t is small enough that we >> could just store it as a blob allocated off the procfs inode or >> something like that without bothering with a shmfs file. You'd be able >> to read(2) the exit status as many times as you wanted. > > I think that, if the syscall in question is read(2), then it should work = *once* per struct file. Otherwise running cat on the file would behave ver= y oddly. Why? The file pointer would work normally. > Read and poll have the same problem as write: we can=E2=80=99t check caps= in read or poll either. Why not? Reading /proc/pid/stat does an access check today and conditionally replaces the exit status with zero.