home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / sys / sun / admin / 9506 < prev    next >
Encoding:
Text File  |  1992-12-16  |  2.3 KB  |  51 lines
  1. Newsgroups: comp.sys.sun.admin
  2. Path: sparky!uunet!utcsri!geac!censor!comspec!noweh.com!georgn
  3. From: georgn@noweh.com (Georg S. Nikodym)
  4. Subject: Re: rdate caused NFS problems on audit directory
  5. In-Reply-To: rjq@phys.ksu.edu's message of 9 Dec 92 21:16:39 GMT
  6. Message-ID: <GEORGN.92Dec16000734@idcrisis.noweh.com>
  7. Sender: georgn@noweh.com (Georg S. Nikodym)
  8. Organization: Noweh Software, Mississauga, CANADA
  9. References: <1g5nnnINN2no@moe.ksu.ksu.edu>
  10. Date: Wed, 16 Dec 1992 05:07:36 GMT
  11. Lines: 38
  12.  
  13. In article <1g5nnnINN2no@moe.ksu.ksu.edu> rjq@phys.ksu.edu (Rob Quinn) writes:
  14.  
  15.     Last night I was adjusting the time on my NFS clients with a script
  16.    that rsh's to each and runs 'rdate bohr' (bohr is my main server). I
  17.    had just adjusted the time on bohr, and I don't think any of the clients
  18.    had their time adjusted more than a few minutes. Immediatly I started
  19.    getting NFS errors from the clients and mail. Here's part of my syslog
  20.    showing what happened to one machine:
  21.    [error messages deleted...]
  22.  
  23.     Using 'showfh' I found that the NFS error was referring to
  24.    /etc/security/audit/bohr/files/19921207054007.not_terminated.boltzman.
  25.    The security partitions are mounted with secure NFS from bohr. 'error 5' is
  26.    EIO, I/O error.
  27.    [more stuff deleted for brevity...]
  28.  
  29.     So, can anyone detail the sequence of what happened here? Does secure nfs
  30.    use a timestamp, that I invalidated when I changed the time? Why did the
  31.    warning messages come from the users on the consoles, and not root?
  32.  
  33. While I won't attempt to detail the sequence of events, I will answer
  34. questions about secure RPC/NFS.  Yes, it does rely on timestamping.
  35. An encrypted timestamp and window get packaged into each RPC request.
  36. A server receiving a timestamp that is earlier than previous ones will
  37. barf.  Using rdate in a secure NFS environment is a Bad Idea(TM).
  38. Investigate other things like ntp that synchronize clocks by skewing
  39. will probably solve your problems.
  40.  
  41. For some information on how secure NFS works, I believe you'll find a
  42. description in the Answerbook.  If you don't have that, you can find
  43. basically the same thing in a white paper on the subject that you can
  44. get by anon FTP from opcom.sun.ca.
  45.  
  46. -- 
  47. Georg S. Nikodym  -  (416) 272-5198 / 720-4729
  48. Noweh Software - Mississauga, Ontario, CANADA
  49. UUCP:    {comspec.com, lsuc.on.ca, uunet.ca}!noweh!georgn
  50. RFC822:    georgn@noweh.COM
  51.