From owner-freebsd-audit Thu Feb 1 17:25:39 2001 Delivered-To: freebsd-audit@freebsd.org Received: from mail.gmx.net (sproxy.gmx.net [194.221.183.20]) by hub.freebsd.org (Postfix) with SMTP id 6A4EA37B67D for ; Thu, 1 Feb 2001 17:25:22 -0800 (PST) Received: (qmail 18030 invoked by uid 0); 2 Feb 2001 01:25:20 -0000 Received: from p3e9bc177.dip.t-dialin.net (HELO forge.local) (62.155.193.119) by mail.gmx.net (mp017-rz3) with SMTP; 2 Feb 2001 01:25:20 -0000 Received: from thomas by forge.local with local (Exim 3.16 #1 (Debian)) id 14OUyR-0000NZ-00; Fri, 02 Feb 2001 02:25:15 +0100 Date: Fri, 2 Feb 2001 02:25:15 +0100 From: Thomas Moestl To: Kris Kennaway Cc: freebsd-audit@FreeBSD.ORG Subject: Re: patch to remove setgid kmem from top Message-ID: <20010202022515.A1453@crow.dom2ip.de> Mail-Followup-To: Thomas Moestl , Kris Kennaway , freebsd-audit@FreeBSD.ORG References: <20010202015844.A1246@crow.dom2ip.de> <20010201171145.A75869@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010201171145.A75869@xor.obsecurity.org>; from kris@obsecurity.org on Thu, Feb 01, 2001 at 05:11:45PM -0800 Sender: owner-freebsd-audit@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Feb 01, 2001 at 05:11:45PM -0800, Kris Kennaway wrote: > > One sysctl, kern.lastpid, had to be added for this. It exports the > > nextpid variable, which reflects the highest PID used up to now. > > Just to be clear, this isn't "the next PID which will be used by a > forked process", but "the PID of the last created process"? I'm pretty > sure the counter is incremented at fork-time (the issue is if we're > doing random PID increments to defeat prediction, we obviously don't > want to tip our hand). The latter is publically available information > and I don't see an issue with this. Yes. nextpid is taken in fork1, incremented by one, then randomness is added (if enabled) and then the needed checks are done etc. This new PID that is going to be used by the just-being-created created process is then written back into newpid. So this shouldn't give the new PID away until the fork is already in process and the PID is assigned. - thomas To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message