On Wed, 12 Jan 2000, Alan Cox wrote:
> > This is also a really bad idea, because with easily guessable pids you
> > are opening yourself to /tmp races. This is actually a argument for
> > random pids (or fixing the programs).
>
> Random pids just slow the process down. Its an argument for writing
> decent code.
Random pids in a 32 bit space would take an average of ~1 random number
generation to calculate per fork. That can't be too slow can it? It would
perhaps be a more stable performance statistic than our current scheme
because the current scheme can hit a block of in-use pids and thus the
time to work out a suitable pid had a greater variance.
WRT the security issues; predictable pids have always assisted the cause
of the cracker. Any extra difficulty we can generate is always
useful. Obviously it's only worth considering for 32bit pids not 16bit.
Cheers
Chris
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Jan 15 2000 - 21:00:21 EST