>> typical Linux configuration. Although you can avoid users to eat
>> resources this way by setting resource limits properly this effect can
>> be considered to be a Linux bug. Linux is protected to avoid
>> allocating all process slots by normal users. There are reserved
>> MIN_TASKS_LEFT_FOR_ROOT slots for root. So there should be also
>> protection to avoid allocating all memory by normal users.
>This seems to be a generic Unix bug. I brought down our SGI with that
>program, and netbsd also seems to jam solid. The general vulnerability
>is going to be the same on all OS's (anyone got an NT port ?) or want
>to make a summary table.
So far as I know, you'll never run NT out of proc table space, since the
limit on nearly every sort of handle under NT is 2^32. You'll cripple it
from RAM usage long before you run into problems with that. The same deal
with handles, except I think that one is only 2^32 per _process_. Don't
think we'll see that turn into much of an issue. 4 billion handles ought
to be enough for anyone <g>
Where you can screw up NT is that the OS has no way to limit any given
user's RAM consumption. So a very simple while(ptr = malloc(somesize));
ought to bring just about any NT box close to it's knees. This sort of
nonsense is, however, fixed in NT 5.0. I have inadvertantly done this to
myself a few times, and it is somewhat interesting - NT gets very, very
slow and quite annoyed. It will continue running, and under some
conditions will get irate and kill the offending process. In fact, I did
this last night on my work machine - came in this morning, logged in, noted
that my app had consumed about 1/4 gig of page+RAM, killed the app and went
about my work.
David LeBlanc |Why would you want to have your desktop user,
dleblanc@mindspring.com |your mere mortals, messing around with a 32-bit
|minicomputer-class computing environment?
|Scott McNealy