Messages in this thread | | | Subject | Re: /proc/sys/kernel/pid_max issues | From | Albert Cahalan <> | Date | 12 Sep 2004 23:20:29 -0400 |
| |
Ingo Molnar writes:
> it's getting quite spaghetti ... do we really want to handle > RESERVED_PID? There's no guarantee that any root daemon wont stray out > of the 1...300 PID range anyway, so if it has an exploitable PID race > bug then it's probably exploitable even without the RESERVED_PID > protection.
Purpose:
1. weak security enhancement 2. cosmetic (backwards, IMHO) 3. speed (avoid PIDs likely to be used)
I'd much prefer LRU allocation. There are lots of system calls that take PID values. All such calls are hazardous. They're pretty much broken by design.
Better yet, make a random choice from the 50% of PID space that has been least recently used.
Another idea is to associate PIDs with users to some extent. You keep getting back the same set of PIDs unless the system runs low in some global pool and has to steal from one user to satisfy another.
BTW, since pid_max is now adjustable, reducing the default to 4 digits would make sense. Try a "ps j" to see the use. (column width changes if you change max_pid)
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |