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

Internet Message Format | 1993-01-09 | 3.6 KB

Path: sparky!uunet!wupost!usc!elroy.jpl.nasa.gov!news.claremont.edu!nntp-server.caltech.edu!SOL1.GPS.CALTECH.EDU!CARL
From: [e-mail] (Carl J Lydick)
Newsgroups: comp.os.vms
Subject: Re: HELP!!! Security problem for gurus. [Directories]
Date: 9 Jan 1993 12:41:07 GMT
Organization: HST Wide Field/Planetary Camera
Lines: 54
Distribution: world
Message-ID: <[e-mail]>
References: <[e-mail]>,<[e-mail]>
Reply-To: [e-mail]
NNTP-Posting-Host: sol1.gps.caltech.edu

In article <[e-mail]>, [e-mail] (Don Stokes) writes:
>> 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!

Hmmm.  I guess you're in a business where the people using your computer don't
give a damn whether or not the results they get are correct, as long as they
get results.  IF THE SYSTEM DISK IS HOSED, YOU CAN'T TRUST THE SYSTEM.  Period.
If you trust anything the system does when the file structure on the system
disk is screwed up, I've got a bridge I'd like to sell you.
>
>Sure, there are situations when security is an overriding considerations.

I'm not talking about security, I'm talking about integrity.  IF THE SYSTEM
DISK IS HOSED, YOU CAN'T TRUST THE SYSTEM TO PROVIDE CORRECT RESULTS.  Period.
Maybe you can hope that this is your lucky day, and the system disk got screwed
up in a benign fashion.  But if you COUNT ON THAT, you're ripping off your
customers.

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

And, in your case, I guess they also don't scream when they spend hours or days
of CPU time to produce incorrect results, hmm?  YOU SEEM INSISTENT ON CONFUSING
SECURITY AND INTEGRITY.   They're related, but they're not the same thing.  A
WRONG ANSWER IS WORSE THAN NO ANSWER AT ALL.

>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 might also result in two people writing to the same blocks allocated to two
separate files.  Result:  Neither file is valid.  You mean to tell me that
you've got customers who are so goddamned stupid they's stand for that sort of
bullshit?
--------------------------------------------------------------------------------
Carl J Lydick | INTERnet: [e-mail] | NSI/HEPnet: SOL1::CARL

Disclaimer:  Hey, I understand VAXen and VMS.  That's what I get paid for.  My
understanding of astronomy is purely at the amateur level (or below).  So
unless what I'm saying is directly related to VAX/VMS, don't hold me or my
organization responsible for it.  If it IS related to VAX/VMS, you can try to
hold me responsible for it, but my organization had nothing to do with it.