lkml.org 
[lkml]   [2000]   [Oct]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: PIDs limited to 15 significant bits
On Sun, Oct 01, 2000 at 01:10:50AM -0400, Albert D. Cahalan wrote:
> Andries Brouwer writes:
> > On Fri, Sep 29, 2000 at 03:57:10PM -0400, Albert D. Cahalan wrote:
>
> >>> My machines regularly see 6- or 7-digit PIDs.
> >
> >> Oh, the horror!
> >>
> >> Consider, do you like to type "kill 1234567890" more than
> >> a simple "kill 1234"?
> >
> > Hmm. I double click on the ps output and single click to paste.
> > The number of digits does not play a role.
>
> I have a real VT510 terminal w/o a mouse, but OK...
> I still don't like to read and compare such numbers.

Ever heard of grep?! Pipe the ps output through grep and then to kill.
Still, it's cool you're doing real stuff with a real terminal. If more
people did, they'd realise that their source-code shouldn't have 150
chars wide lines et al.

> >> What do you think of "ps -efj" on a standard 80x24 screen?
> >
> > I never give such commands, but just tried:
> >
> > aeb 119876 1 426 236 0 23:32 tty1 00:00:00 xterm
> > aeb 119877 119876 119877 119877 0 23:32 pts/9 00:00:00 -bash
> > aeb 119884 119877 119884 119877 0 23:33 pts/9 00:00:00 ps -efj
> >
> > as you see, the ps program here fails to align the columns,
> > but otherwise all is well.
>
> How are you going to like the output after some more uptime?
> The record is around 1200 days I think. With a faster machine
> doing a lot of work, you could just about lose the CMD column.

So, let's see if I get this straight: you want us to limit PID's to
15 bits rather than 31 bits because the output of ps wouldn't look nice
otherwise?! PLEASE... Should we stick to 16 bit UID's because a simple
"ls -nal" might look ugly?! Oh, and du/df will probably start to look
ugly when having those 2 TB sized LV's. Oh my... Better return to non
LFS.

> >>> [The patch is available. There are a few security advantages.
> >>
> >> There should not be any significant security advantages.
> >> One can easily wrap/predict in a 31-bit space.
> >
> > There are a few weaknesses that can be exploited using a wraparound.
> > With 100 processes/sec that takes 497 days with a 32-bit pid
> > and 5 minutes with a 16-bit pid.
>
> David Miller once posted a forks/second rate for SPARC that was
> many thousands... these days, once might wrap once per second.

I agree with this one, though. Hoping for security just by having more
PID's is a bit naive. It might give some increased security, but having
some form of random pid-calculation will give extra overhead on fork
anyway, right?! Is it really worth it?

When you have a 31-bit PID space and people start to manufacture
programs to exploit the wraparound, you'd probably notice.

> So the 31-bit space won't help you much. If you really want
> this kind of security, you should make me an offer for my old PC.
> I'll even pop out the OverDrive, getting you down to 25 MHz.

Uhmmm. Of course, DOS attacks versus such a machine isn't very
complicated anyway...


/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/

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