NetNews Usenet Archive 1993 #1/NN_1993_1.iso/spool/comp/os/vms/20288

Internet Message Format | 1993-01-04 | 3.7 KB

Path: sparky!uunet!munnari.oz.au!comp.vuw.ac.nz!zl2tnm!toyunix!don
Newsgroups: comp.os.vms
Subject: Re: HELP!!! Security problem for gurus. [Directories]
Message-ID: <[e-mail]>
From: [e-mail] (Don Stokes)
Date: 4 Jan 93 14:25:13 GMT
Sender: [e-mail] (GNEWS Version 2.0 news poster.)
References: <[e-mail]>
Distribution: world
Organization: The Wolery
Lines: 61

[e-mail] (Carl J Lydick) writes:
> In article <[e-mail]>, [e-mail] (Don Stokes) writes:
> >RMS won't crash a system at all (unless BUGCHECKFATAL is set).  The XQP might.
> >RMS lives in exec mode; an unhandled condition will at worst take out the
> >process.
>
> That's technically true, but since RMS calls the XQP, the distinction isn't as
> clear as it might otherwise seem.  For example, the first time I was really

Well, the distinction is that it's a lot easier to step on something in a
way to make RMS feel upset than it is to step on something that will make
the XQP barf.  Directories are one case where you can potentially freak the
XQP out, and I have seen the XQP die horribly on bad directories.

When asked, DEC have always considered crashes due to file structure problems
as bugs to be fixed (ie better error checking required), rather than a
natural response to a corrupt filesystem.


> In my humble (STOP THE SNICKERING!) opinion, if the system disk is found to
> have been hosed, the system should shut down NOW!

It looks like our differing backgrounds are showing.  My background is in
systems where organisations' livelihoods depended on the computers running;
they weren't just used for counting the beans at the end of the day.  Downtime
meant slipped deadlines and penalty clauses.  In these cases, it doesn't
matter how stuffed the system is, if you can keep production rolling while you
figure out what to do, you do.  Classic example: a dumpfile was deleted (NOT
BY ME!) without the system being rebooted.  This ws V4.7, and the effect was
that when the system was rebooted weeks later, memory was copied to where
the dumpfile used to be.  A defragger made quite sure there was useful stuff
underneath the dump.  Oops!

I didn't get that problem finally sorted out until a couple of days later.
But the system ran the whole time, and no production time was lost (apart
from < 1/2 an hour at a quiet time while I rebooted the cluster onto a
de-scrozzled system disk).  If the system had died, I'd have had to spend
many long hours backing up the bad disk so I could find out what went wrong,
restoring from backup and picking any changes since the backup.  I'd really
not want to tell those who hold the pursestrings that it was "right" to
crash in a potentially recoverable situation.

Sure, there are situations when security is an overriding considerations.
I believe these are in a minority compared to cases where production is
the overriding consideration.  Users don't scream when a security hole
is opened; they do when the system goes down under them.

It's a simple (hah!) matter of risk management.  In my experience, disk
corruption is very unlikely to open a security hole (it might deny access
by destroying SYSUAF or whatever).  It's certainly more likely to cause
denial of service.  Keeping as much as possible going is one way to
reduce the downtime; crashing could render the system unbootable and
require extensive effort to repair.

Fortunately, DEC seems to agree with me more than you on this one, Carl,
and I'm glad of it!  8-)

--
Don Stokes, ZL2TNM (DS555)                        [e-mail] (home)
Network Manager, Computing Services Centre            [e-mail] (work)
Victoria University of Wellington, New Zealand              [phone]