home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / os / vms / 20684 < prev    next >
Encoding:
Internet Message Format  |  1993-01-09  |  4.1 KB
  1. Path: sparky!uunet!zaphod.mps.ohio-state.edu!usc!wupost!waikato.ac.nz!comp.vuw.ac.nz!zl2tnm!toyunix!don
  2. Newsgroups: comp.os.vms
  3. Subject: Re: HELP!!! Security problem for gurus. [Directories]
  4. Message-ID: <208009@zl2tnm.gen.nz>
  5. From: don@zl2tnm.gen.nz (Don Stokes)
  6. Date: 10 Jan 93 00:23:00 GMT
  7. Sender: news@zl2tnm.gen.nz (GNEWS Version 2.0 news poster.)
  8. References: <1imh53INNg7a@gap.caltech.edu>
  9. Distribution: world
  10. Organization: The Wolery
  11. Lines: 69
  12.  
  13. carl@SOL1.GPS.CALTECH.EDU (Carl J Lydick) writes:
  14. > get results.  IF THE SYSTEM DISK IS HOSED, YOU CAN'T TRUST THE SYSTEM.  Period.
  15. > 
  16. > I'm not talking about security, I'm talking about integrity.  IF THE SYSTEM
  17. > DISK IS HOSED, YOU CAN'T TRUST THE SYSTEM TO PROVIDE CORRECT RESULTS.  Period.
  18. > 
  19. > And, in your case, I guess they also don't scream when they spend hours or days
  20. > of CPU time to produce incorrect results, hmm?  YOU SEEM INSISTENT ON CONFUSING
  21. > SECURITY AND INTEGRITY.   They're related, but they're not the same thing.  A
  22. > WRONG ANSWER IS WORSE THAN NO ANSWER AT ALL.
  23.  
  24. Calm down, Carl, you're hurting my ears.
  25.  
  26. What's very important here is that there is a big difference between 
  27. corrupt memory and a corrupt system disk.  In the former case, you shut 
  28. down NOW and reboot.  When you come up, the problem has almost certainly
  29. gone away, at least until next time.  
  30.  
  31. In the latter case, because disk space is non-volatile, when you crash 
  32. and reboot, the problem *will* *still* *be* *present*.  There wasn't any
  33. point in rebooting, because it doesn't make the problem go away.  Worse,
  34. it may render the system unbootable, so you cannot find out what went
  35. wrong.
  36.  
  37. If you have a live (if sick) system, you have a chance of finding out what
  38. went wrong.  That is *very* important -- the glitch might have taken out
  39. more than a part of the system disk, and you need the error log and stuff
  40. to diagnose it.  You need to know what got stepped on so you can fix it.
  41. Most importantly, you ned the *choice* to be able to fix the problem as
  42. soon as possible, or possibly effect a temporary repair to maintain 
  43. production.  Sure, there are cases where you should shut down Right Now
  44. and boot standalone backup, but in my experience (ignoring total failure,
  45. in which case you don't have a choice) these are extremely rare.  A knee-
  46. jerk "something's wrong, let's die" is the *wrong* way to deal with
  47. discovery of disk problems.  There's not much you can do to diagnose a
  48. disk problem from the >>> prompt, unless you feel like keying in disk
  49. controller instructions by hand.
  50.  
  51. It needs to be up to the system manager to decide how serious the problem
  52. is.  It needs to be possible for the system manager to make that decision. 
  53. In some cases it can be fixed quickly and simply.  Others are going to 
  54. require that you kick the users off the system and get on with fixing it.
  55. Still others will require restore from backup.  But you need to be able
  56. to make that decision. 
  57.  
  58. > It might also result in two people writing to the same blocks allocated to two
  59. > separate files.  Result:  Neither file is valid.  You mean to tell me that
  60. > you've got customers who are so goddamned stupid they's stand for that sort of
  61. > bullshit?
  62.  
  63. No.  I have customers who consider me competant enough to make informed
  64. decisions to provide them with the best possible service, including data
  65. integrity, security and system availablility.  I would object quite strongly
  66. to having that decision taken away from me by an overly paranoid exception
  67. handler.  To me, it's far better to have a good exception reporting 
  68. facility (and VMS has to have one of the better ones out there) that helps
  69. me make that decision than it is to have the decision made for me.  
  70.  
  71.  
  72. Really, Carl, while I respect your competance and helpfulness on the net,
  73. don't you think you could dilute the vitriol a little?  Get a nice hot 
  74. cuppa or a cold beer and relax before hitting the Followup key, huh?  
  75. Your answers may well be better, and certainly far more pleasant to read.
  76. 8-)
  77.  
  78. --
  79. Don Stokes, ZL2TNM (DS555)                        don@zl2tnm.gen.nz (home)
  80. Network Manager, Computing Services Centre            don@vuw.ac.nz (work)
  81. Victoria University of Wellington, New Zealand              +64-4-495-5052
  82.