Date: Fri, 2 Feb 2001 02:25:15 +0100 From: Thomas Moestl <tmoestl@gmx.net> To: Kris Kennaway <kris@obsecurity.org> Cc: freebsd-audit@FreeBSD.ORG Subject: Re: patch to remove setgid kmem from top Message-ID: <20010202022515.A1453@crow.dom2ip.de> In-Reply-To: <20010201171145.A75869@xor.obsecurity.org>; from kris@obsecurity.org on Thu, Feb 01, 2001 at 05:11:45PM -0800 References: <20010202015844.A1246@crow.dom2ip.de> <20010201171145.A75869@xor.obsecurity.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010202022515.A1453>