Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp1811890imu; Sun, 18 Nov 2018 09:18:27 -0800 (PST) X-Google-Smtp-Source: AJdET5eR2Nzmpjjdsibdg8Xto0OKSlFt0NbwtHPL2I+KYY2iqNG0/ZdVPA6SWgqj8Ws3CqDngRTb X-Received: by 2002:a62:b615:: with SMTP id j21-v6mr19746196pff.199.1542561507041; Sun, 18 Nov 2018 09:18:27 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1542561507; cv=none; d=google.com; s=arc-20160816; b=UTxR6+yt6kmcQn5dtNQY6lumT9CTpkr0s4KSuxT2C2/xg1zScTZoJOVkN/MEhFzGbI HFybWB+q79VD2csCckzrI7NPq8c75Q88/NR0RsvuSZ2GeQrnMqGtXDL/NOT1eVtC5ov7 gznY4ZSUnf1FjdkHCTnEiGMLK1DedsTTb/9lvlE6ipeW7TPSM9KM+IEhtxZix5N8rm6D KB9nSbCVCaZcu35J1yfuS1NSscM0Fkrig06KpHHAlrK8eNJzhOTbILdeyaRb0JvdCE9L iFjLcKCs0GZFXMRw++iI6pGc5Jdr2SOlX7sKh7X25k0jxJWNXx7NRsF7CsW1PWqA7gFz gnuw== 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=grI9evRjuC5Yl8ZpNx9BG0kKmO4Je6cBfn+q6L6JCzQ=; b=VSBYgZg2Q5JiIPfucyWmeBpLJeRh0I+3IBR1cV9hUz9GvlnBdGUxftccGW5K0Hftk7 YB81Qium/L6WmyoQlzIpXrBODr02dMu2U9r1eBd6tULzfRymVCyszglxrFXGSjBF2Vv8 pCoNh4ZMJwhZYtWrKe4eBnQjw0Aqj7pS/ru6rJA+L4dAuQ2nmI5TVRPMiqeCofcD3/cF g6BFjS9Z4JCH81Lr2vNwvplHXkOr0hKPFLiZSzGa16u+nwEU8zBRtjc2C7LYWBBeeZQq HsWGFFdm95brcnMCBpNgM1Fp/MG+Q9gWdKThEa5NVtjEZphmNRYSYEGT4vgMGAKYdJ09 thqA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=SnQhawD4; 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 23si16210991pfz.20.2018.11.18.09.18.10; Sun, 18 Nov 2018 09:18:27 -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=SnQhawD4; 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 S1726952AbeKSDiX (ORCPT + 99 others); Sun, 18 Nov 2018 22:38:23 -0500 Received: from mail-ua1-f65.google.com ([209.85.222.65]:34691 "EHLO mail-ua1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726643AbeKSDiW (ORCPT ); Sun, 18 Nov 2018 22:38:22 -0500 Received: by mail-ua1-f65.google.com with SMTP id z23so9708045uam.1 for ; Sun, 18 Nov 2018 09:17:33 -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=grI9evRjuC5Yl8ZpNx9BG0kKmO4Je6cBfn+q6L6JCzQ=; b=SnQhawD4Yb3zY7VcrJWpIrZvFs4Oj9ZshwDmewTdzGEqg/hD9eMMzxlw8Y1PfUMzrq IhYcmBQww7mYweEOPkCVaOjLzgcpRPqxkVceA5yKTqgiBOLSeK4Wt/ah7W1rExGxUAzX m0zNIfT7j5R5ZPBfJLgLSa4JYVNVBtcNT+4ytg57jvkiY1OKJgY844cPvo/s89TSnS6d 9ID8bOMOaa0yLV37WCcSdlNgQv6TGH/wZAUiD2UAMwcvzsPeyBRiP3Mf5z1pJzhElNBO Ef41yBmfTF/d3ypiAIMjG0sEKdCWMMgVGrbW2kJDvR0STJcdSOntH9TRbiH5YPt1c++b zESQ== 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=grI9evRjuC5Yl8ZpNx9BG0kKmO4Je6cBfn+q6L6JCzQ=; b=aVUmP2zMsZKr/7SNQqRfiz1voXdyeITvjZtfEk8aQwVV9CyMpxGST+KjvNkUxsesQy J1awSATgAwGc/kg/zZXwiVJF4vYuyvltTq02/5b3v2bUeucmyk6yYf6NEj4ZKV/ASPIS UqIeOPi4gPJqwhV0fE9c/Wvw5uF9brUa0MlAec6GxBB3rHQyv/7fs2/RX//SS7uO87Wp BuSH0lVbwnNoPiPri/bVh0a4WjBOWIoXE5PdChZkPC0z8ZJqMkGP6wx+VHi0XguH/WkI sEHEYcE+PbVh6KG5fcontqTlZaQLTv7NbZVCCPZ0PAHLFHj/b6narYfDUtC35oQW3Lov rEMQ== X-Gm-Message-State: AGRZ1gI/SqDKSlBVCXg2XDicPmiqZamW9iJyw3zTqTo1OqAUr3/P7vYp PttUbX8V2Xo5FQoihZLpsow+KzGbWcvcalKQzSM/kw== X-Received: by 2002:ab0:45e2:: with SMTP id u89mr8275891uau.13.1542561452731; Sun, 18 Nov 2018 09:17:32 -0800 (PST) MIME-Version: 1.0 Received: by 2002:a67:f48d:0:0:0:0:0 with HTTP; Sun, 18 Nov 2018 09:17:31 -0800 (PST) In-Reply-To: References: <20181118111751.6142-1-christian@brauner.io> From: Daniel Colascione Date: Sun, 18 Nov 2018 09:17:31 -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 9:13 AM, Andy Lutomirski wrote: > On Sun, Nov 18, 2018 at 8:29 AM Daniel Colascione wrote: >> >> On Sun, Nov 18, 2018 at 8:17 AM, Andy Lutomirski wrote: >> > On Sun, Nov 18, 2018 at 7:53 AM Daniel Colascione wrote: >> >> >> >> 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. >> > >> > Linus banned it because of bugs iike the ones in the patch. >> >> Maybe: he didn't provide a reason. What's your point? > > My point is that an API that involves a file like /proc/PID/kill is > very tricky to get right. Here are some considerations: Moot. write(2) for this interface is off the table anyway. The right approach here is a system call that accepts a /proc/pid directory file descriptor, a signal number, and a signal information field (as in sigqueue(2)). > Now if we had an ioctlat() API, maybe it would make sense. But we > don't, and I think it would be a bit crazy to add one. A process is not a driver. Why won't this idea of using an ioctl for the kill-process-by-dfd thing just won't die? An ioctl has *zero* advantage in this context.