home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / os / vms / 12865 < prev    next >
Encoding:
Internet Message Format  |  1992-07-28  |  2.8 KB
  1. Path: sparky!uunet!cs.utexas.edu!usc!sdd.hp.com!caen!kuhub.cc.ukans.edu!parsifal.umkc.edu!cstp.umkc.edu!mckeever
  2. Newsgroups: comp.os.vms
  3. Subject: Re: Q: VMS OWNERSHIP
  4. Message-ID: <1992Jul28.154701.1@cstp.umkc.edu>
  5. From: mckeever@cstp.umkc.edu
  6. Date: Tue, 28 Jul 1992 21:47:01 GMT
  7. Sender: root@parsifal.umkc.edu (Parsifal Administration)
  8. References: <01GMEK6MLDG88WVZ3V@MIS.AVPMI.YORKU.CA>
  9. Organization: UM - Kansas City, Computer Science
  10. Lines: 49
  11.  
  12. In article <01GMEK6MLDG88WVZ3V@MIS.AVPMI.YORKU.CA>, JMCCARTHY@MIS.AVPMI.YORKU.CA (John McCarthy) writes:
  13.  
  14. > The basic problem that I want to solve is to allow someone else (e.g. the 
  15. > departmental secretary) to update a file that I currently own. However, I don't 
  16. > want anybody else to get to it, and I don't want her to be able to change the 
  17. > access rights.
  18. > 
  19. > Having looked at the manual, and done some experimenting, this seems to be the 
  20. > way that it works:
  21. > 
  22. > 1) If I set up an ACL, giving her R+W+E, when she actually changes the file, she 
  23. > is now the owner. Unless I set up an ACL giving myself access to the file, I can 
  24. > no longer update it. In addition, she now has Control access, and could modify 
  25. > the access permissions. 
  26.  
  27. I've been doing VMS for a long time and haven't seen this type of behavior. 
  28. From your message, it looks like the secretary is using an editor to update
  29. a file owned by you.  In that case, she isn't changing the ownership of
  30. your file, she's writing a new one.  Without having privs, the file is
  31. owned by the person who created it (the new version that is).  Thus the
  32. ownership change you see.
  33.  
  34. The fix is not to let her use an editor to update the file.  If she is just
  35. adding info to the end of the file, have her edit a temporary file and then
  36. use APPEND to tack her changes onto the end of the file owned by you.   If
  37. she needs to make random changes all over the file, the workaround is not
  38. as easy.  You'll have to write some sort of program that changes the
  39. contents of the file without writing a new version.  You could have her
  40. edit the file, make her changes, save a temporary file, and then run a C
  41. program that just empties out the old data and rewrites it with the
  42. information in the temporary file.  Not pretty and if it's a big file not
  43. very efficient either.  It seems to me to be the quickest fix though.
  44.  
  45. > 2) If I set up a separate directory, owned by a resource ID, and do the 
  46. > appropriate grants, we can both update the file, and ownership of it doesn't 
  47. > flip around. However, she can still change the access list. It also seems a 
  48. > little strange to have to set up directories and resource IDs for each file in 
  49. > the system that more than one person needs to update.
  50.  
  51. None of this should be necessary although it will work.
  52.  
  53. > Any help would be appreciated. No flames please, as I said, I'm new to this 
  54. > environment.
  55.  
  56. We were all beginners once.
  57.  
  58. Hope you find the above useful,
  59.  
  60. --Brian
  61.