Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp1974526imu; Sun, 18 Nov 2018 12:53:23 -0800 (PST) X-Google-Smtp-Source: AJdET5f9MgYqTPlAV8Ld9GKfz1VkvkpN8kISTDfG5WMJ55tzGh4zzG3wWKEISbWdD6jFk3KH7r4G X-Received: by 2002:a62:6408:: with SMTP id y8mr20023339pfb.202.1542574403662; Sun, 18 Nov 2018 12:53:23 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1542574403; cv=none; d=google.com; s=arc-20160816; b=zPkU83WYaO3LG3tuINVjDGvNkdp+XI66JPx6Ub+vCo1CDr6eW62megFwtw0C+yFvON vfYjZWCQPHBWGgiNC87AXocO8rAOkKKSSOzBxcomaDf/mm/H2wSjaHAywK4izOiRv5tr pVyOEAfrBYBca/2ctHSnTTenFvSk1qL5lR/dsGJKTX9x1cAE3Thi1mnxrNXNepeb7Fpp 1zzIDZVJDGyr/J7o3cC8QUmj3ilmEAvsnHQYMsMwOA4+h1ttCurRMFdYwwtpir/MqgWN JWnA2zO87x1WuZijbd2xNiY6Ihmn6BuClEr0Svq8PLApnymfCTA4n9De30gS0Udck/MH qufA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:to:references:message-id :content-transfer-encoding:cc:date:in-reply-to:from:subject :mime-version:dkim-signature; bh=FUwG6V1I17FoKidXXdsHXAHVVi+GK9rin42p8Ud4644=; b=fpi7ydEgPZsim/6AE5++CWXCKuEt4WFJfb8E0Z42YUt1HdkWnjRtrD70/CCByrPWZy 288Pcv/Gx6xb9VS+qVLGTj40l6LCql1f2KViX+gxOHMNjue38FhI+ExowHbUneYjc/At lsaApcv/u+B1TJypMygz7Zh9FjfpJ0D6X+Ij4HvC5HTfWy1NCRQ2jYPihq6n1YpKCLVj Kmq0B9gdZb2gel2Q0noA2L1ZrQagBhY6jnlUXbGhdK18i8+tsoxWy8zXmgT56KOhCgt1 dfluzngle7GeasvwCByPrLE/VHwN2oUKe/Ly4WRCh9Tl/Ty0/b+jLyk2ZphtkJhMedUg xR6w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@amacapital-net.20150623.gappssmtp.com header.s=20150623 header.b="qo/Nxfta"; 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 k142si18983812pfd.174.2018.11.18.12.53.05; Sun, 18 Nov 2018 12:53:23 -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=@amacapital-net.20150623.gappssmtp.com header.s=20150623 header.b="qo/Nxfta"; 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 S1727089AbeKSGt7 (ORCPT + 99 others); Mon, 19 Nov 2018 01:49:59 -0500 Received: from mail-io1-f68.google.com ([209.85.166.68]:39523 "EHLO mail-io1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726072AbeKSGt7 (ORCPT ); Mon, 19 Nov 2018 01:49:59 -0500 Received: by mail-io1-f68.google.com with SMTP id j18-v6so8723406iog.6 for ; Sun, 18 Nov 2018 12:28:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amacapital-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=FUwG6V1I17FoKidXXdsHXAHVVi+GK9rin42p8Ud4644=; b=qo/NxftaZ01+eUqSB5EH6Hhg+Evk8PRMAo9Dw77YtExuHovL5mxV8QTVVYSDcQzvmb IeYz08bAaQ5AooQZosCM2R3OsizYSmjbFGinnSyIfe71gNqziFJ0OQCd7bmdQgDA1oBC fofrgYJdu2i+ibEtu7YwnyfDx2tZADXbFSgSy2fdvVjtIlVDatiDmQoA9YidO4KWJQkL um7Ky7u2yMYAl4Vmwgfiobe+vM4hRZH9DHoMCESAz1H7mh4+I/wl4j+PK73H3/iPBWRe EX2+AgkIbBXptlb5PfTHKuB5dAIsRTzMknzkTmDXqKe3gX8FEeDT/Y9il+x6kTxGtrjc gYwA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=FUwG6V1I17FoKidXXdsHXAHVVi+GK9rin42p8Ud4644=; b=Hn4aYShKEuzxic4Q6Z6B/ZkH6PlhLukqKyGhiQ8kZG9guf7pOHsk1j7rh15xKyL1jI E3BAHQHvRJL76Ox0wQUwhG/ybhtrr0bSGy/5aLPrppkWnzY5ctiA3pvS7Zg96p/KhMWy a+Vx0L4lrRIJM1lVJOWeirKxFVSjWm8h2uRNBvLiQwhrxd546nfpdJbc3CARL0/LRNU7 y8NlwEfm32BM+hDDQ1Z3N+TFiSf8jM5vBhV9+B3GZJ2DiQlXyK2oE0UW9FZ1oPBi/XW+ O2X1s9kclkuw0qtLzwix4mq2BlRLZ9WUYbZH5LiPAI2+jLIVRwqmYcUgLoxkbKcIy/rp 0k5g== X-Gm-Message-State: AGRZ1gLoyvktE1QEsJKdi7CdGLSPK230zcsOluACEaFu/LCFS+owupB0 zAlH9gKuD5qQ1E1egrMCHjBDBA== X-Received: by 2002:a6b:9382:: with SMTP id v124-v6mr15103381iod.260.1542572923233; Sun, 18 Nov 2018 12:28:43 -0800 (PST) Received: from [192.168.1.143] (c-71-205-112-160.hsd1.co.comcast.net. [71.205.112.160]) by smtp.gmail.com with ESMTPSA id z191-v6sm12892516itb.31.2018.11.18.12.28.42 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 18 Nov 2018 12:28:42 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) Subject: Re: [PATCH] proc: allow killing processes via file descriptors From: Andy Lutomirski X-Mailer: iPhone Mail (16A404) In-Reply-To: Date: Sun, 18 Nov 2018 13:28:41 -0700 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-Transfer-Encoding: quoted-printable Message-Id: <608F2959-800D-46EE-A7CD-8C972ACD2F02@amacapital.net> References: <20181118190504.ixglsqbn6mxkcdzu@yavin> To: Daniel Colascione Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > On Nov 18, 2018, at 12:44 PM, Daniel Colascione wrote:= >=20 >=20 > That is, I'm proposing an API that looks like this: >=20 > int process_kill(int procfs_dfd, int signo, const union sigval value) >=20 > 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 curren= t creds are considered. So it would need to be a different syscall or at le= ast a flag. Otherwise a lot of those nice theoretical properties go away. > 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 *on= ce* per struct file. Otherwise running cat on the file would behave very od= dly. Read and poll have the same problem as write: we can=E2=80=99t check caps in= read or poll either.=