Received: by 2002:ac0:bc90:0:0:0:0:0 with SMTP id a16csp4457962img; Tue, 26 Mar 2019 09:45:39 -0700 (PDT) X-Google-Smtp-Source: APXvYqynR27NSCche/bQR8e+Rb6cXvv2IhFETyaKxj+Z0aDrJfMXjEzamQzj4OxbMM+MgqWFESJp X-Received: by 2002:a63:6142:: with SMTP id v63mr29513072pgb.342.1553618739031; Tue, 26 Mar 2019 09:45:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1553618739; cv=none; d=google.com; s=arc-20160816; b=0L6zlPEM+AdGnXtv2Fh45pLwTTPJCGAn66yPXhFItjPBRiSd2to05Iee0guZ7GVQ7c ureW6J/QlGAIYwyaDLqmvfgfw7nSQXh6HagU2KEZ85ltRtatceDOujUy+QTSAfEJwZTl BiqCkMJjWt+LIxGS/dsNqc7YJCfG0VtAwmktcw1E2eTMxiZmGw1rrWq4UqLFDvukos/3 ni9v75gi9IAOpkZS5jc2ynfgLbcp22iofRPdeV3Lzjg07tHjHEDGjudNrEDz8adFtHgE hDu1r9lPUWy9nj+9B++grHU8rruhzsgizJEx+kzghCyNuGwF+oVPHcdXvmnJ8Nbw2K6P 9CLQ== 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 :in-reply-to:references:mime-version:dkim-signature; bh=ndMjC5owOWitIMu5sAn+PcFJA8JvAfkyRGS4Q8GPiAI=; b=oMU8T6ENZiBUYcdUJJDxiVKphd7Lnr7kmByoI79kjgO8GHFEN//3A+hTl/0ipv86Xy al8qFlP2PWi9qiu9oAv5K4fuGiuy+tvGuDOGpkf6cBqfJFkEBEnpysQ+c+k2sQeKzXZp 3XA6Uf5gVxyzBtm3/lPlMstSCRi3pGY1Zjn4UO+Sq4xfdVOhjKMN+PB6PssEFP5t3eV6 HCVQBFAgTWgVGZmJD6iHXNk92xAgOHGRXDFVtiOlbSulch+c6soVrKjcVA6UElO5TFrh wzNmpebKxsH+VJHt0Gk7YmNGV/9aO94Pte6ChFmhM1xLr/whCDAym/evW7KY/l1/husT 86KQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=qY6V7NpU; 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=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id e11si18320645plb.140.2019.03.26.09.45.22; Tue, 26 Mar 2019 09:45:39 -0700 (PDT) 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=@kernel.org header.s=default header.b=qY6V7NpU; 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=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731679AbfCZQnO (ORCPT + 99 others); Tue, 26 Mar 2019 12:43:14 -0400 Received: from mail.kernel.org ([198.145.29.99]:45504 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730451AbfCZQnN (ORCPT ); Tue, 26 Mar 2019 12:43:13 -0400 Received: from mail-wr1-f50.google.com (mail-wr1-f50.google.com [209.85.221.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 6768A20866 for ; Tue, 26 Mar 2019 16:43:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1553618592; bh=0tfxmRPyDL+6TieH2j63s77iLPVQYtSyxbar+zBk5QY=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=qY6V7NpUZT1W0sBFdMu38Ffb6y+3ojkkBpRlMdyZFrhfQ9CpDlySHOuR8kVBqbxgb /AEvZ+Hf3h6MqxabmB3Bb2Cg5J91h9Fi2siXsC57YempGQm541gxChHzAWIDQ92tWK O4A5c2ex87C34clOhw0X9r2vIe4LjFMeUuPW+e8Y= Received: by mail-wr1-f50.google.com with SMTP id w10so15198631wrm.4 for ; Tue, 26 Mar 2019 09:43:12 -0700 (PDT) X-Gm-Message-State: APjAAAXMhW5adQ4Q4GMei36ZmsGazH58aIAO7DwPPO32uFD/vVNE0uiB mQNoEI+z6O84eu5PGp6f3T8LoyfvjD4Zvv5Q7rhTUg== X-Received: by 2002:a5d:6252:: with SMTP id m18mr19171451wrv.199.1553618590971; Tue, 26 Mar 2019 09:43:10 -0700 (PDT) MIME-Version: 1.0 References: <20190326155513.26964-1-christian@brauner.io> <20190326155513.26964-3-christian@brauner.io> <20190326162337.o256x7hiodu2qfyg@brauner.io> <20190326163142.4eh5qpgiqvygf26w@brauner.io> <20190326163452.uku4bgkessxzxvai@brauner.io> In-Reply-To: <20190326163452.uku4bgkessxzxvai@brauner.io> From: Andy Lutomirski Date: Tue, 26 Mar 2019 09:42:59 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v1 2/4] pid: add pidctl() To: Christian Brauner Cc: Daniel Colascione , Jann Horn , Konstantin Khlebnikov , Andy Lutomirski , David Howells , "Serge E. Hallyn" , "Eric W. Biederman" , Linux API , linux-kernel , Arnd Bergmann , Kees Cook , Alexey Dobriyan , Thomas Gleixner , Michael Kerrisk-manpages , Jonathan Kowalski , "Dmitry V. Levin" , Andrew Morton , Oleg Nesterov , Nagarathnam Muthusamy , Aleksa Sarai , Al Viro , Joel Fernandes 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 Tue, Mar 26, 2019 at 9:34 AM Christian Brauner wrote: > > On Tue, Mar 26, 2019 at 05:31:42PM +0100, Christian Brauner wrote: > > On Tue, Mar 26, 2019 at 05:23:37PM +0100, Christian Brauner wrote: > > > On Tue, Mar 26, 2019 at 09:17:07AM -0700, Daniel Colascione wrote: > > > > Thanks for the patch. > > > > > > > > On Tue, Mar 26, 2019 at 8:55 AM Christian Brauner wrote: > > > > > > > > > > The pidctl() syscalls builds on, extends, and improves translate_pid() [4]. > > > > > I quote Konstantins original patchset first that has already been acked and > > > > > picked up by Eric before and whose functionality is preserved in this > > > > > syscall: > > > > > > > > We still haven't had a much-needed conversation about splitting this > > > > system call into smaller logical operations. It's important that we > > > > address this point before this patch is merged and becomes permanent > > > > kernel ABI. > > > > > > I don't particularly mind splitting this into an additional syscall like > > > e.g. pidfd_open() but then we have - and yes, I know you'll say > > > syscalls are cheap - translate_pid(), and pidfd_open(). What I like > > > about this rn is that it connects both apis in a single syscall > > > and allows pidfd retrieval across pid namespaces. So I guess we'll see > > > what other people think. > > > > There's something to be said for > > > > pidfd_open(pid_t pid, int pidfd, unsigned int flags); > > > > /* get pidfd */ > > int pidfd = pidfd_open(1234, -1, 0); > > > > /* convert to procfd */ > > int procfd = pidfd_open(-1, 4, 0); > > > > /* convert to pidfd */ > > int pidfd = pidfd_open(4, -1, 0); > > probably rather: > > int pidfd = pidfd_open(-1, 4, PIDFD_TO_PROCFD); Do you mean: int procrootfd = open("/proc", O_DIRECTORY | O_RDONLY); int procfd = pidfd_open(procrootfd, pidfd, PIDFD_TO_PROCFD); or do you have some other solution in mind to avoid the security problem?