home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / os / vms / 17675 < prev    next >
Encoding:
Internet Message Format  |  1992-11-09  |  3.0 KB
  1. Path: sparky!uunet!portal!cup.portal.com!Chris_F_Chiesa
  2. From: Chris_F_Chiesa@cup.portal.com
  3. Newsgroups: comp.os.vms
  4. Subject: Re: Q: Homegrown COPY? FAQ?
  5. Message-ID: <69170@cup.portal.com>
  6. Date: Mon,  9 Nov 92 08:36:49 PST
  7. Organization: The Portal System (TM)
  8. References: <1992Nov2.043637.29321@netcom.com> <bjVRf?se@twinsun.com>
  9.   <68931@cup.portal.com> <1992Nov6.094353.239@rlgsc.com>
  10. Lines: 66
  11.  
  12. In response to an earlier article of mine, in which I said
  13.  
  14. >>   Basically, I want to allow non-privileged users to copy files to which the
  15. >> existing baseline VMS protections/ACLs don't allow them access, subject to
  16. >> "permissions" "granted" by the owners of the files.  [...] 
  17.  
  18. Robert "Bob" Gezelter (gezelter@rlgsc.com) writes:
  19.  
  20. >Instead of re-writing COPY, how about using a daemon process 
  21. >(there is at least one in the DECUS library) to grant/revoke 
  22. >identifiers at the requested 'dates-and-times'. [...]
  23.  
  24. That sounds perfect!  Any thoughts on where I might find those/that
  25. daemon(s) in the DECUS library?  I'll write my own if I must, but it'd
  26. be interesting and helpful to see how other folks have already done it.
  27.  
  28. I'd also want to be able to generate multiple, independent identifiers that
  29. could be granted to different users, groups, etc...  Do(es) the existing
  30. daemon(s) support that?  A single identifier for everyone wouldn't give me
  31. sufficient granularity. 
  32.  
  33. >While it would be rather CPU inefficient, you could even write 
  34. >the daemon in DCL and use AUTHORIZE to manage the grant/revoke 
  35.  
  36. Interesting thought...
  37.  
  38. >All of the mechanisms for implementing interprocess 
  39. >communications are, for most intents and purposes, at the same 
  40. >security level. If you have sufficient privileges to snoop on a 
  41. >global section, you can probably snoop (or at least disrupt) a 
  42. >mailbox. 
  43.  
  44. Yeah, I've run across this "snoop a GS, snoop a mailbox" concept before,
  45. but I wouldn't know how to do EITHER of these...
  46.  
  47. >My personal preference for interprocess communications 
  48. >is through DECnet, which makes the case of LAVc and other 
  49. >clustered systems easier.
  50.  
  51. Not an issue in my case: I'm not clustered (I'm barely even NETWORKED) and
  52. don't expect to become so.
  53.  
  54. >>   Thanks in advance,
  55. >> 
  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. Thanks again.
  65.  
  66. (For the record, folks, I want to thank those who have responded via E-mail;
  67. Carl Lydick, with whom I am still discussing servers similar to the one Bob
  68. mentioned here; Harry Flowers who pointed me toward looking at how C-Swing
  69. does its file copying; Thomas Hopson who sent me source code for a similar
  70. utility, GIVE, that he wrote; and Arne Vaxhxj (?) who suggested something I
  71. could try to make my "$IMGACTing COPY.EXE" trick work properly.  Also for
  72. the record, Arne's suggestion worked and my $IMGACT trick now does too!  It's
  73. a kick to see something I wrote, spit out a message "before" and "after" a
  74. filling of totally COPY-esque behavior.)
  75.  
  76. Chris Chiesa
  77.   Chris_F_Chiesa@cup.portal.com
  78.