* Andries Brouwer (aeb@veritas.com) wrote:
> So, in the long run we want a large pid_t. What about the short run?
> For today the disadvantages are negligeable, and for people who
> like security there are definite advantages.
Much more the problem is giving people the *impression* of
actual security advantage.
> David, I already said the same to someone else:
> Security is not a yes/no matter. It is a matter of less or more.
> Thus, "Hoping for security" is meaningless.
> But "Hoping for more security by having more PID's" is quite
> reasonable. If I am local user on your system then I can break in
> using a wraparound. If that takes 2147483647 processes I have to
> wait longer than when that takes 32000 processes.
Yes, it does, but it doesn't increase security signifigantly.
Trying to claim it does just seems completely nutty. There are
certainly other reasons for a larger pid, and personally I would find
it reasonable for it to be a config option, but if someone came up to
me and said I should be using 32bit pids because it's more secure than
15bit pids I'd laugh at them.
So, how about a patch that adds it in as a config option with
an appropriate default? My personal feeling is that the default should
be 15bit because it's what is currently used and has no chance of
breaking anything. Admittedly, nothing *should* break w/ 32bit pids,
but then reality steps in. Would be nice to see what does break.
Stephen
This archive was generated by hypermail 2b29 : Sat Oct 07 2000 - 21:00:09 EST