home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / os / vms / 20273 < prev    next >
Encoding:
Internet Message Format  |  1993-01-04  |  4.7 KB
  1. Path: sparky!uunet!usc!elroy.jpl.nasa.gov!news.claremont.edu!nntp-server.caltech.edu!SOL1.GPS.CALTECH.EDU!CARL
  2. From: carl@SOL1.GPS.CALTECH.EDU (Carl J Lydick)
  3. Newsgroups: comp.os.vms
  4. Subject: Re: HELP!!! Security problem for gurus. [Directories]
  5. Date: 4 Jan 1993 09:31:00 GMT
  6. Organization: HST Wide Field/Planetary Camera
  7. Lines: 70
  8. Distribution: world
  9. Message-ID: <1i904kINNdbj@gap.caltech.edu>
  10. References: <1i6dd2INNrct@gap.caltech.edu>,<14628002@zl2tnm.gen.nz>
  11. Reply-To: carl@SOL1.GPS.CALTECH.EDU
  12. NNTP-Posting-Host: sol1.gps.caltech.edu
  13.  
  14. In article <14628002@zl2tnm.gen.nz>, don@zl2tnm.gen.nz (Don Stokes) writes:
  15. >RMS won't crash a system at all (unless BUGCHECKFATAL is set).  The XQP might.
  16. >RMS lives in exec mode; an unhandled condition will at worst take out the 
  17. >process.  
  18.  
  19. That's technically true, but since RMS calls the XQP, the distinction isn't as
  20. clear as it might otherwise seem.  For example, the first time I was really
  21. scorched in an INFO-VAX flame, a guy by the name of Jerry Leichter on the
  22. machine (I think; I'm probably pretty close to the right name)
  23. venus.ycc.yale.edu took strong exception to one of my posts.  In the post to
  24. which he was responding, I pointed out that having a directory with zero blocks
  25. allocated to it could crash you system.  This would happen any time you tried
  26. to access a file in the directory (i.e., any time you used a directory lookup
  27. involving that directory as a directory, not simply as a file in another
  28. directory;  I hope this makes sense;  I've gotten a bit verbose because there's
  29. another thread going on about the distinction between dealing with a directory
  30. as a file, and dealing with it as a directory).  Jerry's gripe wasn't that I
  31. pointed this out; he objected to my including code that used an unsupported RMS
  32. routine to truncate the directory).  Somehow it doesn't seem fair:  I got
  33. flamed for including all the necessary code to reproduce my problem :-).
  34.  
  35. >As for case (4), a corrupt system disk is _not_ a good reason to crash
  36. >the system.  In many cases keeping the thing up could be the difference
  37. >between a clean recovery and having to restore from backup (possibly
  38. >causing loss of data from between the last backup and the crash, at
  39. >best losing valuable production time);
  40.  
  41. But if a trusted image has been corrupted, it can potentially do nasty things
  42. to files on ALL your disks.  Especially if the image in question is the one
  43. that handles all disk I/O on the system.  I'd much rather have to do an image
  44. restore of my system disk (I can always get it restored to within a week ago)
  45. than risk having corrupted data in the files my users are *REALLY* interested
  46. in.
  47.  
  48. >ANALYZE/DISK/REPAIR _does_ work on a system disk.
  49.  
  50. Usually.  But what if the contents of a file are corrupted?  What if RMS
  51. somehow decides to write to SYSUAF.DAT instead of reading from it (yeah, I
  52. know, if it does that, at worst SYSUAF.DAT becomes unusable;  but there are
  53. other files that might not be so robust).  If the stuff that handles all disk
  54. I/O knows that it's sick, it should quit.  RIGHT NOW (well, YESTERDAY would be
  55. better, but that doesn't seem possible).
  56.  
  57. >Of course if it's really scrozzled you might need to
  58. >crash it and restore anyway.  I can't think of any reason for the system
  59. >to crash because it discovers a damaged file structure (as opposed to
  60. >crashing because it ate something poisonous as a result), nor can I recall
  61. >anyone losing a system because of file structure damage.
  62.  
  63. Well, I don't have the listings at hand, but, let's suppose:  RMS gets damaged
  64. in such a way that when JOE_USER logs in, when RMS looks up the rightslist
  65. identifiers he holds (part of loginout), it misreads RIGHTSLIST.DAT in such a
  66. way as to assign him an identifier we'd created to allow someone to modify,
  67. say, SYSTARTUP_V5.COM?  Could that perhaps be considered a problem?  I'm not
  68. claiming that it's likely, just that it's possible.  What if we had a file in
  69. SYS$COMMON:[*...] that was normally supposed to be used, and one in
  70. SYS$SPECIFIC:[*...] that we used for development purposes, and somehow the
  71. system disk got hosed in such a way that we could only find the one in
  72. SYS$SPECIFIC?
  73.  
  74. In my humble (STOP THE SNICKERING!) opinion, if the system disk is found to
  75. have been hosed, the system should shut down NOW!
  76. --------------------------------------------------------------------------------
  77. Carl J Lydick | INTERnet: CARL@SOL1.GPS.CALTECH.EDU | NSI/HEPnet: SOL1::CARL
  78.  
  79. Disclaimer:  Hey, I understand VAXen and VMS.  That's what I get paid for.  My
  80. understanding of astronomy is purely at the amateur level (or below).  So
  81. unless what I'm saying is directly related to VAX/VMS, don't hold me or my
  82. organization responsible for it.  If it IS related to VAX/VMS, you can try to
  83. hold me responsible for it, but my organization had nothing to do with it.
  84.