Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp1738583imu; Sun, 18 Nov 2018 07:55:03 -0800 (PST) X-Google-Smtp-Source: AFSGD/UOv34qRf0cNkhieHhoxPghQJaFMxHe94EOIsscRTUKBDXmgjsSLtZLlofZwagfT9ibqEo6 X-Received: by 2002:a17:902:887:: with SMTP id 7mr8888468pll.164.1542556503374; Sun, 18 Nov 2018 07:55:03 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1542556503; cv=none; d=google.com; s=arc-20160816; b=jLI2/P6xdbew97foASEyw47XmedtiZpPKdG+M+mma/d7Rxdta2xVjfPwpl+7b1r6Ft ywBj28U0r0dGNltti/FDK4odrq1N+hWJHpMFLlQEqT5PWyUdwV57jfOQBlvbKGk9ONx9 kEIbsOmHj7g5rwGK2oSNVUCXxiitXU0ZvkpVqw4IhJ8cOnDp73Hw/gb/jHYGKwQrYRZV CZZZ9E9/1zCmG5L+hqwjdWJyiA2/VySU3PkQmWW3LzBgvdc15tOsEDkwhB10uaR284jq oUUVccvw33z+YfA9tJCe6tQpIBY4+AOHrg1moYClIFFxc7VVFZ9JXQKualCU0Sz9UHBR pSDA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature; bh=oAvELmMDfLLvCTgSAORCiReuErvoUldHbTRk39dK5Xg=; b=YA43aFLD7BWCtWAI7KYvQz12jrLUpgIbeFq+87Dzhxb2EXZUcg0eXXYYiEN7eCy87N Vd76dJTVktdJGbXIbUlJR4UiAT9vQtn79apKZytYxCN4Qpd+8ZZZlnlbmLiQELUbJHz1 4XBfQRUKftDgwztKrA4snFPQojbEK5QF2IET1RUIqTNb8/TLETAXVe44avlH3YoD1rg5 HxExNPzF/ziE/uVf8kNtk2dORIHdw4U+jZ0uK/nSTSmHzeHSk/4nIiMoTxQAnm/DTqkA NzSOg+DFOQ5zMpsfcRghfGPESHGj8kIP856hp8miCYcmZweRy5e5EtMiChBr9eMByaMu vRig== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=JKBFdrsw; 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 e1-v6si39342638plk.4.2018.11.18.07.54.35; Sun, 18 Nov 2018 07:55:03 -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=JKBFdrsw; 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 S1727502AbeKSCOI (ORCPT + 99 others); Sun, 18 Nov 2018 21:14:08 -0500 Received: from mail-vs1-f66.google.com ([209.85.217.66]:34815 "EHLO mail-vs1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726643AbeKSCOI (ORCPT ); Sun, 18 Nov 2018 21:14:08 -0500 Received: by mail-vs1-f66.google.com with SMTP id y27so16430654vsi.1 for ; Sun, 18 Nov 2018 07:53:29 -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; bh=oAvELmMDfLLvCTgSAORCiReuErvoUldHbTRk39dK5Xg=; b=JKBFdrswEeNtAlPwpfrMMuX8pnFLLpB+5DJh6lQE3Ev6z2oLY/DgoFP48aLefmsnyl skU665wmSeTLWBhVzQHMYt7VF5wZLt7s9UAz0E2ee30wIPzinpL0/C4+NW4MS188EjOP wrVjTa4uRI3g+r+blRu7twZ1RUilEWQPWBiWf6Tgs1R1YIX6TJjGd2FvK+wYjo8jRL/5 6F+WcPBuqXlmERBWP7FpOJbLBKGjtO9/qQC8otNVurBpowLufgNL9693ZXOQDyqwclcf ti7UU8xMmpTSllBGh3u73kPahFrCaO8/YAw2nO2GpMNrzif6WdBPmOa2X7hZKN1CsAZb D99w== 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; bh=oAvELmMDfLLvCTgSAORCiReuErvoUldHbTRk39dK5Xg=; b=HkXfGUFx+ZwIBkTqH4SySbr6JcokSadS09Ve024hThBK/D6HfaC5ao5nQFqdfaCetD tHYnShaiPYVPpbPyep82L26/rFJzJ+87bSiLNMMtrOJulEfjrI2FL9/uDr6jANLu0Nkv L+zoFjY6jOHBG/M9S935EvvnSrruG42BsIeZ+6SW66Nf4UFJGPedqjz0QrS9doGMAhxZ eBQm2WVDiPqbM/q16/RpDdTObkIKsGaVLWvvF3LporrrYK6cbcFa28HlTabn5t/P28wU vxTccDpb9UeuTKiG0K6+8E1DcQeQjM6VIQgcBSWgcSsxPN58EtfbouiSTr6juVwzZF4j YgqA== X-Gm-Message-State: AGRZ1gJjFWuk/F662jCZY3JIpqXO3fHQPb5GzAPpWvtwioHlprYnynjT UWfUHgA5pUU+OFRfiLDTj4gpT7ULCF7eZTWkkYBzMQ== X-Received: by 2002:a67:6e87:: with SMTP id j129mr7846561vsc.171.1542556408696; Sun, 18 Nov 2018 07:53:28 -0800 (PST) MIME-Version: 1.0 Received: by 2002:a67:f48d:0:0:0:0:0 with HTTP; Sun, 18 Nov 2018 07:53:27 -0800 (PST) In-Reply-To: References: <20181118111751.6142-1-christian@brauner.io> From: Daniel Colascione Date: Sun, 18 Nov 2018 07:53:27 -0800 Message-ID: Subject: Re: [PATCH] proc: allow killing processes via file descriptors To: Andy Lutomirski Cc: Christian Brauner , "Eric W. Biederman" , LKML , "Serge E. Hallyn" , Jann Horn , Andrew Morton , Oleg Nesterov , Aleksa Sarai , Al Viro , Linux FS Devel , Linux API , Tim Murray , Kees Cook Content-Type: text/plain; charset="UTF-8" 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 7:38 AM, Andy Lutomirski wrote: > 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. > 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, 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.