🚀 go-pugleaf

mrc@Tomobiki-Cho.CAC.Washington.EDU (Mark Crispin) writes:

>I believe that it is perfectly reasonable to claim that it is a bug in
>the kernel if the kernel crashes just because some user consumed all
>of a particular resource.

>Bug #1: the user should not have been allowed to consume the entire
>resource.  There should be a high-water mark for individual user use.
>If the resource is something that the kernel also needs, there should
>also be a high-water mark for total user use beyond which only the
>kernel or privileged users can tread.  Disk space has the latter type
>of high-water mark.

>Bug #2: the kernel should not have crashed when the resource ran out.
>It should have rejected the fatal attempt to get the resource.  If it
>felt really nasty, it could have killed the process (which would have
>freed things up quite nicely!).

>Bug #3: it is a bug in the minds of `propeller heads' (to quote Steve
>Jobs) that it is EVER anything other than a bug for a kernel to crash.
>It may be a bug in the hardware.  It may be a bug in the software.  It
>can be malicious physical damage (induced hardware bug).  But no
>kernel should crash because of the actions of an unprivileged user
>program.

>Back in prehistoric days (before UNIX), we actually tried to make
>operating systems that would not crash even with the most abusive user
>programs running.  We succeeded, too.  It is embarassingly easy for an
>unprivileged user to crash even so-called `secure' UNIX systems,
>including in ways that cause filesystem damage.  This is an Achilles'
>Heel, and one that should not be tolerated in a `UNIX for the masses'
>system as NeXT claims to be.

Excellent points, and I would extend them to other aspects of the
environment as well, such as the Window Server.  It's frustrating to
work with certain software packages that can cause the Window Server
to crash and wipe out ones entire login session.  This should not be
tolerated, whether it's the result of a bug in the software package
or in the Window Server.

A primary goal of a protected, multi-user, multi-tasking OS is to
isolate processes from each other, so if one causes trouble, the
others are not affected.  Of course, this goal is defeated if there's
a problem with one of the high-level system processes (who watches the
watchers).

And no, I'm not pointing the finger at any particular software.  The
vendor of one package I have that had this Window Server problem has
provided pretty swell support so far, sending up a version that hasn't
clobbered my machine since the update (although admittedly I haven't
used the package as much since the update).
-- 
Royce Howland   --   Everything is IMHO   |  "I can eat enormous quantities
royce@splunge.uucp        (NeXTMail OK)   |   of ice-cream without being sick,
or kakwa!atlantis!splunge!royce           |   Mrs. S-C-U-M."
C86Net: Mr._Neutron@RT.Alta               |   --Mr. Neutron