Re: Potenitial security hole in the kernel

> > Hi folks, > > Please correct me if i'm wrong but it seems to me that i've stumbled on > really BIG security hole in the signal handling code. > The problem IMO is that the signal handling code stores a processor context > on the user-mode stack frame which is active while > the signal

Re: Potenitial security hole in the kernel

Hi folks, Please correct me if i'm wrong but it seems to me that i've stumbled on really BIG security hole in the signal handling code. The problem IMO is that the signal handling code stores a processor context on the user-mode stack frame which is active while the signal handler is

Re: 32-bit pid_t / security

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

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