From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.1 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SPF_PASS,USER_AGENT_NEOMUTT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id BB931C04E53 for ; Wed, 15 May 2019 14:16:40 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 883D32084E for ; Wed, 15 May 2019 14:16:40 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=brauner.io header.i=@brauner.io header.b="gAJyzptk" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728237AbfEOOQk (ORCPT ); Wed, 15 May 2019 10:16:40 -0400 Received: from mail-ed1-f67.google.com ([209.85.208.67]:41609 "EHLO mail-ed1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728229AbfEOOQj (ORCPT ); Wed, 15 May 2019 10:16:39 -0400 Received: by mail-ed1-f67.google.com with SMTP id m4so30114edd.8 for ; Wed, 15 May 2019 07:16:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brauner.io; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=5teuJo4XSRrnL6XxnC+QODipuz2WCzByYGo45sEdpQE=; b=gAJyzptkeah2CnPVHf8ki6Ey+Aje7kt4hiLFQY/UoXftAeb5KMt9kDcge1dL70700f v4lzCF24qKMgoDDJqK48PCIsuOAEIEWh56QloYL0Zx1Ytcl8wEHGZj2FHlHTDjeh1xHN qgtG9Lh2tYpVWiUdw1UsD0iGHta3lP4Ta8QIkzIE14Ud+jGfSqHpCDEAvWIr2Z7unvQT 7zkggOJrHmZj/c4eERJMnDK2ju7392d0B+Atitgv36pLJz4hMjFGB1lnPt+6SoqUGyah IPYOEdYPIgWXRHQq6puWtz6SFEJeqqmkoJuWNHfimIVIYgR96+2ydELKuFEvw/jF51Hq +B1g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=5teuJo4XSRrnL6XxnC+QODipuz2WCzByYGo45sEdpQE=; b=arhokvFodJxdcA8ihjIGquDGXxdSZ9mHnB1DTJszoHZV1A6/zFzv7mM+cle4flA+QK gZtcr6wU9ehCK/GAkMIFPU+pa4NFZQesywZXuoeYw47mbmCCmavqr28YrifnQAgZuncj nJ5HO+FuNcWEj/5Aa694ntq4laJLQWp9BkloNscvLUCGgf+KoIpCM9/oGQzyzaV8FmlH kWI37uofFjARsSv4D8iH1WKVuiYhnRUlPFTIVfqLN/iGLE6FSQoTuyn1m0lVWzqgYOBN KasWwBl/QDopw098nRm4XWYeiwMt7kW6nmqrhzH5uY0ikoK7Mdw7J39zz+9Hr+27DA0h +iog== X-Gm-Message-State: APjAAAWyq3l0ZS93wXK+0ywIHKmpW5Bx0zl7Yb+UX099oxd95gS7UUyp 4wPv6Hhi4SjnbA/5GQGjuVzsKw== X-Google-Smtp-Source: APXvYqz/5w9Bko49z66nfUW8rJGtWbKGmV1irTYSDrNlaxrZSh+Ve4PPN0bCyixGXoTczpolwiOJ2g== X-Received: by 2002:a50:8bbb:: with SMTP id m56mr44288042edm.230.1557929797459; Wed, 15 May 2019 07:16:37 -0700 (PDT) Received: from brauner.io ([178.19.218.101]) by smtp.gmail.com with ESMTPSA id h13sm493114ejs.3.2019.05.15.07.16.35 (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Wed, 15 May 2019 07:16:36 -0700 (PDT) Date: Wed, 15 May 2019 16:16:35 +0200 From: Christian Brauner To: Yann Droneaud Cc: jannh@google.com, oleg@redhat.com, viro@zeniv.linux.org.uk, torvalds@linux-foundation.org, linux-kernel@vger.kernel.org, arnd@arndb.de, dhowells@redhat.com, akpm@linux-foundation.org, cyphar@cyphar.com, ebiederm@xmission.com, elena.reshetova@intel.com, keescook@chromium.org, luto@amacapital.net, luto@kernel.org, tglx@linutronix.de, linux-alpha@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-ia64@vger.kernel.org, linux-m68k@lists.linux-m68k.org, linux-mips@vger.kernel.org, linux-parisc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-s390@vger.kernel.org, linux-sh@vger.kernel.org, sparclinux@vger.kernel.org, linux-xtensa@linux-xtensa.org, linux-api@vger.kernel.org, linux-arch@vger.kernel.org, linux-kselftest@vger.kernel.org Subject: Re: [PATCH 1/2] pid: add pidfd_open() Message-ID: <20190515141634.lrc5ynllcmjr64mn@brauner.io> References: <20190515100400.3450-1-christian@brauner.io> <4c5ae46657e1931a832def5645db61eb0bf1accd.camel@opteya.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4c5ae46657e1931a832def5645db61eb0bf1accd.camel@opteya.com> User-Agent: NeoMutt/20180716 Sender: linux-mips-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-mips@vger.kernel.org On Wed, May 15, 2019 at 04:00:20PM +0200, Yann Droneaud wrote: > Hi, > > Le mercredi 15 mai 2019 à 12:03 +0200, Christian Brauner a écrit : > > > > diff --git a/kernel/pid.c b/kernel/pid.c > > index 20881598bdfa..237d18d6ecb8 100644 > > --- a/kernel/pid.c > > +++ b/kernel/pid.c > > @@ -451,6 +452,53 @@ struct pid *find_ge_pid(int nr, struct > > pid_namespace *ns) > > return idr_get_next(&ns->idr, &nr); > > } > > > > +/** > > + * pidfd_open() - Open new pid file descriptor. > > + * > > + * @pid: pid for which to retrieve a pidfd > > + * @flags: flags to pass > > + * > > + * This creates a new pid file descriptor with the O_CLOEXEC flag set for > > + * the process identified by @pid. Currently, the process identified by > > + * @pid must be a thread-group leader. This restriction currently exists > > + * for all aspects of pidfds including pidfd creation (CLONE_PIDFD cannot > > + * be used with CLONE_THREAD) and pidfd polling (only supports thread group > > + * leaders). > > + * > > Would it be possible to create file descriptor with "restricted" > operation ? > > - O_RDONLY: waiting for process completion allowed (for example) > - O_WRONLY: sending process signal allowed Yes, something like this is likely going to be possible in the future. We had discussion around this. But mapping this to O_RDONLY and O_WRONLY is not the right model. It makes more sense to have specialized flags that restrict actions. > > For example, a process could send over a Unix socket a process a pidfd, > allowing this to only wait for completion, but not sending signal ? > > I see the permission check is not done in pidfd_open(), so what prevent > a user from sending a signal to another user owned process ? That's supposed to be possible. You can do the same right now already with pids. Tools like LMK need this probably very much. Permission checking for signals is done at send time right now. And if you can't signal via a pid you can't signal via a pidfd as they're both subject to the same permissions checks. > > If it's in pidfd_send_signal(), then, passing the socket through > SCM_RIGHT won't be useful if the target process is not owned by the > same user, or root. > > > + * Return: On success, a cloexec pidfd is returned. > > + * On error, a negative errno number will be returned. > > + */ > > +SYSCALL_DEFINE2(pidfd_open, pid_t, pid, unsigned int, flags) > > +{ > > + int fd, ret; > > + struct pid *p; > > + struct task_struct *tsk; > > + > > + if (flags) > > + return -EINVAL; > > + > > + if (pid <= 0) > > + return -EINVAL; > > + > > + p = find_get_pid(pid); > > + if (!p) > > + return -ESRCH; > > + > > + rcu_read_lock(); > > + tsk = pid_task(p, PIDTYPE_PID); > > + if (!tsk) > > + ret = -ESRCH; > > + else if (unlikely(!thread_group_leader(tsk))) > > + ret = -EINVAL; > > + else > > + ret = 0; > > + rcu_read_unlock(); > > + > > + fd = ret ?: pidfd_create(p); > > + put_pid(p); > > + return fd; > > +} > > + > > void __init pid_idr_init(void) > > { > > /* Verify no one has done anything silly: */ > > Regards. > > -- > Yann Droneaud > OPTEYA > >