From: carl@SOL1.GPS.CALTECH.EDU (Carl J Lydick)
Newsgroups: comp.os.vms
Subject: Re: HELP!!! Security problem for gurus. [Directories]
Date: 4 Jan 1993 09:31:00 GMT
Organization: HST Wide Field/Planetary Camera
Distribution: world
Reply-To: carl@SOL1.GPS.CALTECH.EDU
NNTP-Posting-Host: sol1.gps.caltech.edu

In article <14628002@zl2tnm.gen.nz>, don@zl2tnm.gen.nz (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
scorched in an INFO-VAX flame, a guy by the name of Jerry Leichter on the
machine (I think; I'm probably pretty close to the right name)
venus.ycc.yale.edu took strong exception to one of my posts.  In the post to
which he was responding, I pointed out that having a directory with zero blocks
allocated to it could crash you system.  This would happen any time you tried
to access a file in the directory (i.e., any time you used a directory lookup
involving that directory as a directory, not simply as a file in another
directory;  I hope this makes sense;  I've gotten a bit verbose because there's
another thread going on about the distinction between dealing with a directory
as a file, and dealing with it as a directory).  Jerry's gripe wasn't that I
pointed this out; he objected to my including code that used an unsupported RMS
routine to truncate the directory).  Somehow it doesn't seem fair:  I got
flamed for including all the necessary code to reproduce my problem :-).

>As for case (4), a corrupt system disk is _not_ a good reason to crash
>the system.  In many cases keeping the thing up could be the difference
>between a clean recovery and having to restore from backup (possibly
>causing loss of data from between the last backup and the crash, at
>best losing valuable production time);

But if a trusted image has been corrupted, it can potentially do nasty things
to files on ALL your disks.  Especially if the image in question is the one
that handles all disk I/O on the system.  I'd much rather have to do an image
restore of my system disk (I can always get it restored to within a week ago)
than risk having corrupted data in the files my users are *REALLY* interested
in.

>ANALYZE/DISK/REPAIR _does_ work on a system disk.

Usually.  But what if the contents of a file are corrupted?  What if RMS
somehow decides to write to SYSUAF.DAT instead of reading from it (yeah, I
know, if it does that, at worst SYSUAF.DAT becomes unusable;  but there are
other files that might not be so robust).  If the stuff that handles all disk
I/O knows that it's sick, it should quit.  RIGHT NOW (well, YESTERDAY would be
better, but that doesn't seem possible).

>Of course if it's really scrozzled you might need to
>crash it and restore anyway.  I can't think of any reason for the system
>to crash because it discovers a damaged file structure (as opposed to
>crashing because it ate something poisonous as a result), nor can I recall
>anyone losing a system because of file structure damage.

Well, I don't have the listings at hand, but, let's suppose:  RMS gets damaged
in such a way that when JOE_USER logs in, when RMS looks up the rightslist
identifiers he holds (part of loginout), it misreads RIGHTSLIST.DAT in such a
way as to assign him an identifier we'd created to allow someone to modify,
say, SYSTARTUP_V5.COM?  Could that perhaps be considered a problem?  I'm not
claiming that it's likely, just that it's possible.  What if we had a file in
SYS$COMMON:[*...] that was normally supposed to be used, and one in
SYS$SPECIFIC:[*...] that we used for development purposes, and somehow the
system disk got hosed in such a way that we could only find the one in
SYS$SPECIFIC?

In my humble (STOP THE SNICKERING!) opinion, if the system disk is found to
have been hosed, the system should shut down NOW!
--------------------------------------------------------------------------------
Carl J Lydick | INTERnet: CARL@SOL1.GPS.CALTECH.EDU | 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.
Newsgroups: comp.os.vms