Newsgroups: comp.os.vms
Subject: Re: HELP!!! Security problem for gurus. [Directories]
From: don@zl2tnm.gen.nz (Don Stokes)
Date: 10 Jan 93 00:23:00 GMT
Distribution: world
Organization: The Wolery

carl@SOL1.GPS.CALTECH.EDU (Carl J Lydick) writes:
> get results.  IF THE SYSTEM DISK IS HOSED, YOU CAN'T TRUST THE SYSTEM.  Period.
> 
> 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.
> 
> 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.

Calm down, Carl, you're hurting my ears.

What's very important here is that there is a big difference between 
corrupt memory and a corrupt system disk.  In the former case, you shut 
down NOW and reboot.  When you come up, the problem has almost certainly
gone away, at least until next time.  

In the latter case, because disk space is non-volatile, when you crash 
and reboot, the problem *will* *still* *be* *present*.  There wasn't any
point in rebooting, because it doesn't make the problem go away.  Worse,
it may render the system unbootable, so you cannot find out what went
wrong.

If you have a live (if sick) system, you have a chance of finding out what
went wrong.  That is *very* important -- the glitch might have taken out
more than a part of the system disk, and you need the error log and stuff
to diagnose it.  You need to know what got stepped on so you can fix it.
Most importantly, you ned the *choice* to be able to fix the problem as
soon as possible, or possibly effect a temporary repair to maintain 
production.  Sure, there are cases where you should shut down Right Now
and boot standalone backup, but in my experience (ignoring total failure,
in which case you don't have a choice) these are extremely rare.  A knee-
jerk "something's wrong, let's die" is the *wrong* way to deal with
discovery of disk problems.  There's not much you can do to diagnose a
disk problem from the >>> prompt, unless you feel like keying in disk
controller instructions by hand.

It needs to be up to the system manager to decide how serious the problem
is.  It needs to be possible for the system manager to make that decision. 
In some cases it can be fixed quickly and simply.  Others are going to 
require that you kick the users off the system and get on with fixing it.
Still others will require restore from backup.  But you need to be able
to make that decision. 

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

No.  I have customers who consider me competant enough to make informed
decisions to provide them with the best possible service, including data
integrity, security and system availablility.  I would object quite strongly
to having that decision taken away from me by an overly paranoid exception
handler.  To me, it's far better to have a good exception reporting 
facility (and VMS has to have one of the better ones out there) that helps
me make that decision than it is to have the decision made for me.  


Really, Carl, while I respect your competance and helpfulness on the net,
don't you think you could dilute the vitriol a little?  Get a nice hot 
cuppa or a cold beer and relax before hitting the Followup key, huh?  
Your answers may well be better, and certainly far more pleasant to read.
8-)

--
Don Stokes, ZL2TNM (DS555)                        don@zl2tnm.gen.nz (home)
Network Manager, Computing Services Centre            don@vuw.ac.nz (work)
Victoria University of Wellington, New Zealand              +64-4-495-5052
Newsgroups: comp.os.vms