Philip Hazel wrote:
> Folks, I need some feedback.
>
> 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 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; and (ii) in constructing unique file names, for maildir in
> particular. (The original maildir "rules" suggested doing it this way.)
>
> I was going to post some ideas for discussion here, but it got rather
> long, so instead I have put them in a file at
>
> http://cus.cam.ac.uk/~ph10/exim-pid-message
>
> Feedback is invited. I guess it's best on the list so everybody can see
> the discussion (if one ensues).
For maildir, just add some more noise (micro or maybe millisecs), btw
anyone else recognized that most of Mr. Bernsteins suggestions are
unuseable? (adding the device id, etc...)
For MSG-IDs the most compatible way will be No.2, tools depending on the
current format will not need a rewrite. And 2B is the best one ;)
The question is, does all Unices provide a way to retrieve the
milliseconds in a useable resolution? (I just know gettimeofday() so
far, to get the microsecs)
And No.1 would be good for exim 5, but for exim4 I would stay with the
current format :)
And whoever came up with random PIDs should be shot and buried on a moon
far far away ;)
Nico
