Quoth Philip Hazel on Thu, Jan 30, 2003:
> It has been brought to my attention that the long-established Unix
> tradition of allocating process ID numbers sequentially, and wrapping
> around at some limit (usually 32767) is breaking down. OpenBSD
> apparently no longer does this. It is argued that making the "next"
> process id unpredictable improves security.
The code to do this on OpenBSD 3.2-STABLE is in
/sys/kern/kern_fork.c lines 192-195:
/* Find an unused pid satisfying 1 <= lastpid <= PID_MAX */
do {
lastpid = 1 + (randompid ? arc4random() : lastpid) % PID_MAX;
} while (pidtaken(lastpid));
(randompid is 1 by default).
After looking inside the functions, nowhere do I see a promise
not to recycle PIDs in one second. But note that, on traditional
UNIX systems, if a process which lived almost long enough for a
PID to overflow overflow dies, the next process may get its PID.
> The problem is that Exim, along with a lot of other software, assumes
> that the same process id will never be re-used within one second. This
> assumption is used in Exim in two places: (i) in constructing message
> ids;
Isn't the last number (-00) incremented in case a file exists?
> and (ii) in constructing unique file names, for maildir in
> particular.
You can also have an automatically incremented number in this
case. Or a pseudo-random number. This way, you may not even
notice that you had the same PID.
And, after all, you can always use mkstemp(3) where it exists,
and mktemp(3) where it doesn't, feeding them a filename with time
and PID encoded, such as "tttttt-pppppp-XXXXXX". Make it
configurable, and on *really* busy systems in the far future you
will only have to increase the number of 'X's.
Vadik.
--
This is a test. This is only a test. Had this been a real
emergency, you would all be dead by now.
