Messages in this thread | | | From | Oliver Xymoron <> | Subject | Re: RFC/PATCH: Random pid generation | Date | Thu, 13 Jan 2000 20:40:00 -0600 |
| |
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/
| |