Re: RFC/PATCH: Random pid generation

[Mike Coleman]

"Sean Hunter" <[e-mail]> writes:
> > > > And they do that in order to get a unique number, not a random number.
> > > 
> > > This is also a really bad idea, because with easily guessable pids you
> > > are opening yourself to /tmp races.
> > 
> > There can be only one process with a given pid at a time, so there can't
> > be anything I'd call a race.
> 
> You run your program, but I have created a simlink in /tmp with the
> same name (because the name is guessable).  That is a race because it
> relies on contention between two processes (my "ln -s" and your broken
> program) over a shared resource (the easily-guessable name in the
> shared namespace of the filesystem).  This is the definition of a
> race.  You may not call it that, but everyone else would.

You're mixing two things together.  A process can consider its pid to be
unique in the sense that any other process that looks at *its* pid will see a
different number.  This is true and there's never a race involved.  I believe
this is what AC is saying.

If the process' code assumes that certain objects with names based on its pid
(e.g., temp files) will or won't exist (or whatever), then that's a bad
assumption, but it's not in itself a race either.

If the process' code tries to determine or enforce the status of a file with a
certain name in a non-atomic way (using stat or unlink) and then to "quickly"
open a file with that name, *that* is a race.  (Whether or not the name
contains the pid is irrelevant.)

--Mike

-- 
Any sufficiently adverse technology is indistinguishable from Microsoft.