Messages in this thread | | | Date | Mon, 2 Oct 2000 11:47:41 +0200 | From | David Weinehall <> | Subject | Re: 32-bit pid_t / security |
| |
On Mon, Oct 02, 2000 at 04:16:44AM +0200, Andries Brouwer wrote: > On Sun, Oct 01, 2000 at 07:51:13PM +0200, David Weinehall wrote: > > > Hoping for security just by having more > > PID's is a bit naive. > > *1* > It is strange that people do not really seem to understand > the case for a 32-bit pid_t. > This case is: "16 bits is not enough". > > We all know that 640KB was enough, and that 1024 cylinders was enough, > and ten or twenty years later these assumptions turned out to be very > inconvenient. > > Today 32000 processes is enough - I rarely see more than 500. > But there will be a moment in time when 32000 no longer is enough. > If we have to change anyway, changing early is better than > changing late. There always are people with unusual needs.
If you read my entire post, rather than just the part that you quoted, you'll see that I argue FOR, not against, a larger pid_t, based on just these grounds; I know that sooner or later, we'll need those extra processes. Well, my 486 won't...
> *2* > 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. > > 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.
Again, read the entire post, not just the part you quoted. PLEASE? Even just the quote. "[...]JUST by having more PID's[...]". The paragraph this stands in continues with a reasoning on how much easier it would be to assume that someone's trying to break into your machine when's he's doing a forkbomb and trying to eat 31 bits of PID's rather than just 15...
Please, I'm with you on this one, not against you. I want pid_t to be increased. I'd rather see it sooner than later. What I meant was simply that _purely_ making the move out of security reasons might not be reasonable.
/David _ _ // David Weinehall <tao@acc.umu.se> /> Northern lights wander \\ // Project MCA Linux hacker // Dance across the winter sky // \> http://www.acc.umu.se/~tao/ </ Full colour fire </ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
| |