Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp1772080imu; Sun, 18 Nov 2018 08:31:36 -0800 (PST) X-Google-Smtp-Source: AJdET5cKMowss4g3YpiOpC/WNQfR4e2lszlAycwO2Le9ENAONDDJuDuQXGg57zoVgE/MQYH50lQg X-Received: by 2002:a62:798f:: with SMTP id u137mr16677902pfc.168.1542558696395; Sun, 18 Nov 2018 08:31:36 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1542558696; cv=none; d=google.com; s=arc-20160816; b=JYuFU5u5lwT1F6JOEuA4MDGlGdKEPTdBx2TtWSGQ22Uy2s+xNrlSxdg0OSBkkDQxxk zW+3IAH4lwX4d4OqrFQA3Vnb5N0lID/XevXiBeivdpdUg0g1SHkX8jaFcpF8tRbr/yqb 4OL84l+9S4m0+Yx0zVJqoa4EmuOaqksqrwy5+xjiOYrTlGhR7AKda64ylIfk+xyU6LR9 KCpllEN/9CC8bRVyvSbWM0LHX7Zbn1Xhkc0eRdr32yQ9FfSYkWo1qQBNut3X3Jnzgl8M ieIwjsLszrw4gaK5doykIfBSUkX14/S8fXBUULkDUU1rW1iWOtIo8k0T9cFsiJG1uhip Z/fA== 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=8BTlG+U6crX6f99a8da9qr+s5BE0MjwGdyEN+HrRM2Q=; b=KsEKdKN90h/ZUpuE6zyCENFnJjtTI7RBCv5y3maQou/UCK4UZUlPwTO4YP0ega18Y1 pK9LPKVPgWYA7M2wUhKsK489yG5fAvs10y+FGxZmxQ+aKgrOFnExQE4CXgcWW9+0M9KP od+ycnZ24O5x6ad0R9Fxfi6gElUjy4NDaHePn+J5k2dy4dhaRNT/CskIaGfSbaYF0V11 7GSsa3ReEOqLeBmlXfuG2C9degyddirCGahnlT1VY6UcqnQx8Aa19l/ISAYJLDtwbHNN 9M+a7r/K7KpPDFelFAwnO/MIpQaGEcLVx5JdwC00h2Xyyzbum17+Vnh77ssasO2hJt+I dC/Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=TIKpueHc; 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 j14si36161355pgi.354.2018.11.18.08.31.20; Sun, 18 Nov 2018 08:31:36 -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=TIKpueHc; 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 S1727502AbeKSCuI (ORCPT + 99 others); Sun, 18 Nov 2018 21:50:08 -0500 Received: from mail-ua1-f65.google.com ([209.85.222.65]:46611 "EHLO mail-ua1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726746AbeKSCuI (ORCPT ); Sun, 18 Nov 2018 21:50:08 -0500 Received: by mail-ua1-f65.google.com with SMTP id v24so9874815uap.13 for ; Sun, 18 Nov 2018 08:29:25 -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=8BTlG+U6crX6f99a8da9qr+s5BE0MjwGdyEN+HrRM2Q=; b=TIKpueHc3aLoiE715+/ixJZT81uEdDOrTeL4BR2RTvve7Hm3F7uUN1JHSvyVt1lg2q u76LAm7zJnwuOELWHHC95rg0C9eJ7Qe4nihiOAlEO0dWTfeJihHRky3PF8+cMsZmLMJT /s6sG2aU9mC5spf+QaC+sg8PsyUswlLp2k5R+CRXa/FSLbPQlkd4TZzpHDDs+6OTP3vD e0Y4e01I8mV409oyBH819sPKvVAbBcP/vWUCJgRME1t9KeO4oK4YfD/TBZNGzhpf76KP 1mPnnCLChrL5GXpuFTpTRu3HYGuB+EUh8ezf1UCvZIAuZxvyw1aE0AZURHtCdksJsxlw DW7Q== 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=8BTlG+U6crX6f99a8da9qr+s5BE0MjwGdyEN+HrRM2Q=; b=jsPCgVFMeneNrE4vjAPKznSebWHiLzNCYb6HGis4RrQg1q5IF8r+7+Z8VIBT7usNRp PU+tdnmqH1sPRwXGPQeA1KaoddvhnSpwVaeRUrQAc/8jzJweAt7Uvq2uymlFkKGisADB p+mN2QsYil6Eoe1Zl3B0fZW3J70qTSv+SssZF8Mif8ectgeWl+uGOnCYfPhHF80/dDny VAND5jFT6k2HSm9RVtDpg5Iarb8aKaBrdoPG3/kUrwh79wCm5IscXHoyFvCNuzGZj8k4 m00Xn53bpVLhPp8JJpZnRoCDwksYzU9QGebo9DBLvWrJcrl9Vrffo1XlncWI8nU341aO wLoA== X-Gm-Message-State: AGRZ1gLiEjRN/12fFTaejsq0cdhKPQ1rzhcCHAJvQ9kf3cUB4+4x77kH Gw9ht62fTNCwcHtfCW0AtJtZzP0VGHGpEbp7gqqaC6c09i5OjA== X-Received: by 2002:ab0:225a:: with SMTP id z26mr8563954uan.100.1542558564775; Sun, 18 Nov 2018 08:29:24 -0800 (PST) MIME-Version: 1.0 Received: by 2002:a67:f48d:0:0:0:0:0 with HTTP; Sun, 18 Nov 2018 08:29:24 -0800 (PST) In-Reply-To: References: <20181118111751.6142-1-christian@brauner.io> From: Daniel Colascione Date: Sun, 18 Nov 2018 08:29:24 -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 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? >> > 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 > > I don't think I ever saw that review. https://lore.kernel.org/lkml/CAKOZuevXXqwJepmLNUtrU=f8jtdgdKAzUAnAA2+KVcWoMxMyFg@mail.gmail.com/ >> 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. > > I agree it's weird. It might be better to have /proc/PID/exit_status > and make *that* pollable. That's exactly what my patch provides. I feel like we're rehashing the previous discussion.