Re: 32-bit pid_t / security

2000-10-04 Thread Michael van den broek
On Wed, 4 Oct 2000, Richard B. Johnson wrote: > On Wed, 4 Oct 2000, Michael van den broek wrote: > > > > > > > On Wed, 4 Oct 2000, Richard B. Johnson wrote: > > > > > On Tue, 3 Oct 2000, Brett Frankenberger wrote: > > > > > > > > > > > > > S/390 folks run 70,000 sessions active within the

Re: 32-bit pid_t / security

2000-10-04 Thread Richard B. Johnson
On Wed, 4 Oct 2000, Mark Hahn wrote: > > Linux 2.2.17 only allows 255 processes at any one time. Is this a > ... > > Can't fork any more after 255 processes > > ulimit -u > > getting back OT, current entry-level PCs (duron/600) can easily > do 7000 fork/wait pairs per second. Maybe I have a br

Re: 32-bit pid_t / security

2000-10-04 Thread Richard B. Johnson
On Wed, 4 Oct 2000, Michael van den broek wrote: > > > On Wed, 4 Oct 2000, Richard B. Johnson wrote: > > > On Tue, 3 Oct 2000, Brett Frankenberger wrote: > > > > > > > > > > S/390 folks run 70,000 sessions active within the same 60 second period off > > > > one big box. Not on Linux (yet ;))

Re: 32-bit pid_t / security

2000-10-04 Thread Mark Hahn
> Linux 2.2.17 only allows 255 processes at any one time. Is this a ... > Can't fork any more after 255 processes ulimit -u getting back OT, current entry-level PCs (duron/600) can easily do 7000 fork/wait pairs per second. - To unsubscribe from this list: send the line "unsubscribe linux-kerne

Re: 32-bit pid_t / security

2000-10-04 Thread Michael van den broek
On Wed, 4 Oct 2000, Richard B. Johnson wrote: > On Tue, 3 Oct 2000, Brett Frankenberger wrote: > > > > > > > S/390 folks run 70,000 sessions active within the same 60 second period off > > > one big box. Not on Linux (yet ;)) but its worth bearing in mind. > > > > Linux 2.2.17 only allows 2

Re: 32-bit pid_t / security

2000-10-04 Thread Richard B. Johnson
On Tue, 3 Oct 2000, Brett Frankenberger wrote: > > > > S/390 folks run 70,000 sessions active within the same 60 second period off > > one big box. Not on Linux (yet ;)) but its worth bearing in mind. > Linux 2.2.17 only allows 255 processes at any one time. Is this a 'feature'. If so, there i

Re: 32-bit pid_t / security

2000-10-03 Thread Brett Frankenberger
> > S/390 folks run 70,000 sessions active within the same 60 second period off > one big box. Not on Linux (yet ;)) but its worth bearing in mind. Yes, but they don't do it with 7 separate processes (or "address spaces" to use the 390 terminology). They have a few processes/address spaces

Re: 32-bit pid_t / security

2000-10-02 Thread Andries Brouwer
On Mon, Oct 02, 2000 at 11:47:41AM +0200, David Weinehall wrote: > > 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

Re: 32-bit pid_t / security

2000-10-02 Thread Alan Cox
> On Mon, 2 Oct 2000 11:27:16 +0100 (BST), > Alan Cox <[EMAIL PROTECTED]> wrote: > >S/390 folks run 70,000 sessions active within the same 60 second period off > >one big box. Not on Linux (yet ;)) but its worth bearing in mind. > > FYI, OS/390 Unix System Services uses a halfword for the maximu

Re: 32-bit pid_t / security

2000-10-02 Thread Keith Owens
On Mon, 2 Oct 2000 11:27:16 +0100 (BST), Alan Cox <[EMAIL PROTECTED]> wrote: >S/390 folks run 70,000 sessions active within the same 60 second period off >one big box. Not on Linux (yet ;)) but its worth bearing in mind. FYI, OS/390 Unix System Services uses a halfword for the maximum number of

Re: 32-bit pid_t / security

2000-10-02 Thread Alan Cox
> 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... S/390 folks run 70,000 sessions active within

Re: 32-bit pid_t / security

2000-10-02 Thread David Weinehall
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

Re: 32-bit pid_t / security

2000-10-01 Thread Stephen Frost
* Andries Brouwer ([EMAIL PROTECTED]) 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 a

Re: 32-bit pid_t / security

2000-10-01 Thread Andries Brouwer
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