home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / os / vms / 17594 < prev    next >
Encoding:
Internet Message Format  |  1992-11-08  |  3.6 KB

  1. Path: sparky!uunet!charon.amdahl.com!pacbell.com!ames!saimiri.primate.wisc.edu!zaphod.mps.ohio-state.edu!usc!rutgers!cmcl2!rlgsc.com!gezelter
  2. From: gezelter@rlgsc.com
  3. Newsgroups: comp.os.vms
  4. Subject: Re: Q: Homegrown COPY? FAQ?
  5. Message-ID: <1992Nov6.094353.239@rlgsc.com>
  6. Date: 6 Nov 92 14:43:53 GMT
  7. References: <1992Nov2.043637.29321@netcom.com> <bjVRf?se@twinsun.com> <68931@cup.portal.com>
  8. Organization: Robert Gezelter Software Consultant, Flushing, NY
  9. Lines: 65
  10.  
  11. In article <68931@cup.portal.com>, Chris_F_Chiesa@cup.portal.com writes:
  12. Chris,
  13.  
  14. An interesting problem! I have a couple of suggestions and observations 
  15. on some of your questions. 
  16. > ...
  17. >   Basically, I want to allow non-privileged users to copy files to which the
  18. > existing baseline VMS protections/ACLs don't allow them access, subject to
  19. > "permissions" "granted" by the owners of the files.  VMS protections/ACLs could
  20. > probably do the job IF they could be made to take effect, and expire (and the
  21. > corresponding ACL disappear from the file), at predetermined dates-and-times.) 
  22. >  
  23. Instead of re-writing COPY, how about using a daemon process 
  24. (there is at least one in the DECUS library) to grant/revoke 
  25. identifiers at the requested 'dates-and-times'. The daemon 
  26. process need have no communications with the actual user 
  27. processes. User processes will be able to use COPY, or any other 
  28. program that they wish, to access the file. All of the sensitive 
  29. security related code can be isolated to the daemon, which, in 
  30. any event, will only be granting/revoking identifiers. 
  31.  
  32. While it would be rather CPU inefficient, you could even write 
  33. the daemon in DCL and use AUTHORIZE to manage the grant/revoke 
  34. operations. No privileged images need be written/installed. 
  35. Additionally, the daemon will run from protected files in a 
  36. protected account, so it will not be a hazard.
  37. >   * Implementing my project as a client which communicates with a detached
  38. >     server process running a DCL command procedure which verifies the client
  39. >     commands and then issues actual VMS COPY commands.  Has the advantage
  40. >     that it uses "real VMS COPY," and can therefore support the full normal
  41. >     behavior of same.  Has the disadvantage that now I have to deal with 
  42. >     security-of-interprocess-communication issues.  What's the most secure
  43. >     way to have these things talk to each other?  Mailboxes?  Shared global
  44. >     sections?  Lock manager?
  45. All of the mechanisms for implementing interprocess 
  46. communications are, for most intents and purposes, at the same 
  47. security level. If you have sufficient privileges to snoop on a 
  48. global section, you can probably snoop (or at least disrupt) a 
  49. mailbox. My personal preference for interprocess communications 
  50. is through DECnet, which makes the case of LAVc and other 
  51. clustered systems easier.
  52.  
  53. > ... deleted ...
  54. >
  55. >   Thanks in advance,
  56. >     Chris Chiesa
  57. >     Chris_F_Chiesa@cup.portal.com
  58. -- 
  59.  
  60. I hope that the above is of assistance. If you have any 
  61. questions, or if I can be of assistance, please feel free to 
  62. contact me via Email or phone.
  63.  
  64. - Bob
  65. +--------------------------------------------------------------------------+
  66. | Robert "Bob" Gezelter                       E-Mail:  gezelter@rlgsc.com  |
  67. | Robert Gezelter Software Consultant         Voice:   +1 718 463 1079     |
  68. | 35-20 167th Street, Suite 215               Fax:       (on Request)      |
  69. | Flushing, New York  11358-1731                                           |
  70. | United States of America                                                 |
  71. +--------------------------------------------------------------------------+
  72.