[lkml]   [2000]   [Oct]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: 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

_ _
// David Weinehall <> /> Northern lights wander \\
// Project MCA Linux hacker // Dance across the winter sky //
\> </ Full colour fire </
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:39    [W:0.101 / U:1.616 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site