home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / unix / misc / 3528 < prev    next >
Encoding:
Internet Message Format  |  1992-09-08  |  2.7 KB
  1. Xref: sparky comp.unix.misc:3528 comp.sys.sun.admin:6169
  2. Newsgroups: comp.unix.misc,comp.sys.sun.admin
  3. Path: sparky!uunet!decwrl!access.usask.ca!ccu.umanitoba.ca!mills
  4. From: mills@ccu.umanitoba.ca (Gary Mills)
  5. Subject: Re: yp (nis) map changes - how do they happen
  6. Message-ID: <1992Sep6.024242.24232@ccu.umanitoba.ca>
  7. Keywords: passwd yp nis
  8. Organization: University of Manitoba, Winnipeg, Canada
  9. References: <1992Aug27.180340.729@ilinx.wimsey.bc.ca> <janet.714981984@dunnart> <1992Aug30.131151.13011@jupiter.sun.csd.unb.ca>
  10. Date: Sun, 6 Sep 1992 02:42:42 GMT
  11. Lines: 38
  12.  
  13. [comp.sys.sun.admin added; hi Tony]
  14. In <1992Aug30.131151.13011@jupiter.sun.csd.unb.ca> jaf@jupiter.sun.csd.unb.ca (J Anthony Fitzgerald) writes:
  15.  
  16. >This brings up another question for me.  What locking mechanism (if any) does
  17. >yppasswdd use for the password file.
  18.  
  19. It uses a lockfile with a name derived by appending ``.ptmp'' to the name
  20. of your NIS passwd base file.  The locking is apparently done around the
  21. edit of the file, but not around the NIS make.
  22.  
  23. >I have been concerned because of the possibility of yppasswdd updating the
  24. >password file between the time the script reads in the password and group
  25. >files and the rewriting of those files after applying changes.  I have been
  26. >assuming that the yppasswdd changes would be quietly lost.  It would be
  27. >quite simple to add a perl flock call to the script but I would like to be
  28. >assured that this would fix any potential problem.  So far, the scripts seem
  29. >to have caused no problem, but it might be a simple case of no one ever having
  30. >used yppasswd while the script was running.
  31.  
  32. In this case, you might want to just kill and restart yppasswd before and
  33. after you run the script.  You could also have the script create, and
  34. respect the same lockfile.  However, some versions of yppasswdd will exit
  35. ungracefully if they discover that somebody else has created the lockfile.
  36.  
  37. There is some danger of corrupting the NIS base file if both yppasswdd and
  38. your script attempt to update it at the same time.  In addition, if two
  39. users change their password at the same time, both makes running at the
  40. same time will surely corrupt the NIS password maps.  Usually, one of them
  41. becomes empty.  This can also happen if a human or your script does the
  42. make at the same time as a user changes his password.  There is no locking
  43. in the Makefile to protect against this.
  44.  
  45. I fixed this under 4.1.2 by finding a version of yppasswdd, from one of
  46. the 4.1.1 C2 security patches, that waits when the lockfile is present,
  47. and by adding locking to the Makefile.  When I refered the problem to Sun,
  48. the response was that it's a known bug, and is not fixed.
  49. -- 
  50. -Gary Mills-         -Networking Group-          -U of M Computer Services-
  51.