On Thu, 13 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.
Clearly the security reasons are bogus, but weren't there efficiency
reasons for wanting random pids? Like the time it took to find an empty
slot in the process table for rapidly forking processes? I seem to
remember a thread about this about a year back.
Sequential processes are nice for sysadmins, it makes it possible to
figure out execution order occassionally, estimate how quickly processes
are forking, etc. Programs that rely on randomness of time() getpid() for
any form of security are so naive that they likely have numerous other
exploitable problems and no simple concession by the kernel is going to
help matters.
-- "Love the dolphins," she advised him. "Write by W.A.S.T.E.."- 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:25 EST