From owner-freebsd-current@freebsd.org Sun Jul 9 16:53:07 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 106A3D90A68 for ; Sun, 9 Jul 2017 16:53:07 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from theravensnest.org (xvm-110-62.dc2.ghst.net [46.226.110.62]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "theravensnest.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A7DF46551A for ; Sun, 9 Jul 2017 16:53:05 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from [192.168.1.65] (host86-147-116-38.range86-147.btcentralplus.com [86.147.116.38]) (authenticated bits=0) by theravensnest.org (8.15.2/8.15.2) with ESMTPSA id v69GhRMK006492 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 9 Jul 2017 16:43:28 GMT (envelope-from theraven@FreeBSD.org) X-Authentication-Warning: d60e724c-75b0-4b63-9702-f4a9d2bf6793: Host host86-147-116-38.range86-147.btcentralplus.com [86.147.116.38] claimed to be [192.168.1.65] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Getting PID of socket client From: David Chisnall In-Reply-To: <684e8346-c4a8-a0c5-cb2a-cd5159d2af1c@gmx.net> Date: Sun, 9 Jul 2017 17:43:22 +0100 Cc: Johannes Lundberg , freebsd-current Content-Transfer-Encoding: quoted-printable Message-Id: References: <684e8346-c4a8-a0c5-cb2a-cd5159d2af1c@gmx.net> To: Stefan Ehmann X-Mailer: Apple Mail (2.3273) 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 16:53:07 -0000 On 9 Jul 2017, at 14:25, Stefan Ehmann wrote: >=20 > 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. David