From owner-freebsd-current@freebsd.org Sun Jul 9 21:02:41 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 10D67D95C10 for ; Sun, 9 Jul 2017 21:02:41 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mailout.stack.nl (mailout05.stack.nl [IPv6:2001:610:1108:5010::202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mailout.stack.nl", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id CEA6B70653; Sun, 9 Jul 2017 21:02:40 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mailout.stack.nl (Postfix) with ESMTP id 7D90A69; Sun, 9 Jul 2017 23:02:38 +0200 (CEST) Received: by snail.stack.nl (Postfix, from userid 1677) id 65D0528497; Sun, 9 Jul 2017 23:02:38 +0200 (CEST) Date: Sun, 9 Jul 2017 23:02:38 +0200 From: Jilles Tjoelker To: David Chisnall Cc: Stefan Ehmann , Johannes Lundberg , freebsd-current Subject: Re: Getting PID of socket client Message-ID: <20170709210238.GA51240@stack.nl> References: <684e8346-c4a8-a0c5-cb2a-cd5159d2af1c@gmx.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jul 2017 21:02:41 -0000 On Sun, Jul 09, 2017 at 05:43:22PM +0100, David Chisnall wrote: > On 9 Jul 2017, at 14:25, Stefan Ehmann wrote: > > Don't why the structs are not compatible, maybe because: > > "The process ID cmcred_pid should not be looked up (such as via the > > KERN_PROC_PID sysctl) for making security decisions. The sending > > process could have exited and its process ID already been reused for > > a new process." > Note that having the kernel provide a process descriptor instead of a > PID would allow the userspace process to have race-free access to the > PID. This is an interesting idea, but would require quite a few changes. First, current process descriptors act as an artificial parent process, suppressing the normal SIGCHLD to the parent and not being matched by a wildcard waitpid() or similar function. A new kind of process descriptor would have to be added which leaves this behaviour unchanged and could exist in parallel with a process descriptor from pdfork(). Second, pdgetpid() makes no guarantees whether the process ID still exists. It should not make them either for this case, since this would allow another user to hold onto process slots for RLIMIT_NPROC. The only solution would be to add variants of the necessary calls that take a process descriptor instead of a process ID. -- Jilles Tjoelker