home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / os / vms / 20389 < prev    next >
Encoding:
Text File  |  1993-01-05  |  1.3 KB  |  33 lines
  1. Newsgroups: comp.os.vms
  2. Path: sparky!uunet!haven.umd.edu!decuac!pa.dec.com!engage.pko.dec.com!nntpd.lkg.dec.com!star.enet.dec.com!buda
  3. From: buda@star.enet.dec.com (Mark A. Buda)
  4. Subject: Re: HELP!!! Security problem for gurus. [Directories]
  5. Message-ID: <1993Jan5.192320.28541@nntpd.lkg.dec.com>
  6. Sender: usenet@nntpd.lkg.dec.com (USENET News System)
  7. Organization: Digital Equipment Corporation
  8. Date: Tue, 5 Jan 1993 19:21:07 GMT
  9. Lines: 22
  10.  
  11.  
  12. In article <4JAN199310390710@jhuvms.hcf.jhu.edu>, ecf_stbo@jhuvms.hcf.jhu.edu (Remember Grimalkin) writes...
  13.  
  14. >RMS would call the XQP would do rightslist and other protection checking. You
  15. >can't bypass ACL checking by doing file i/o with $qio. I would be more worried
  16. >about its handling of global buffers, if you want to talk about how a hosed RMS
  17. >used by one user could affect the whole system. I realize this is picky, but
  18. >what the hell.
  19.  
  20. There is a whole lineage of palces that could deliver coprrupt data over
  21. and beyond RMS's global buffers.  The whole I/O subsystem, including caching
  22. products are just as risky.
  23.  
  24. Your idea of RMS Global buffers and a possible corruption is much like the I/O
  25. subsystem writing a block of data to the wrong LBN.  It is possible, highly
  26. unkikely as has been proven over time.
  27.  
  28.     - mark
  29.  
  30. buda@star.enet.dec.com
  31. ...!decwrl!star.enet.dec.com!buda
  32. buda%star.enet.dec.com
  33.