From owner-freebsd-current Fri Jan 8 14:22:30 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA03872 for freebsd-current-outgoing; Fri, 8 Jan 1999 14:22:30 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from aurora.sol.net (aurora.sol.net [206.55.65.76]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA03863 for ; Fri, 8 Jan 1999 14:22:21 -0800 (PST) (envelope-from jgreco@aurora.sol.net) Received: (from jgreco@localhost) by aurora.sol.net (8.8.8/8.8.8/SNNS-1.02) id QAA01047 for current@freebsd.org; Fri, 8 Jan 1999 16:21:50 -0600 (CST) From: Joe Greco Message-Id: <199901082221.QAA01047@aurora.sol.net> Subject: 3.0R and NTP, security changes in settimeofday To: current@FreeBSD.ORG Date: Fri, 8 Jan 1999 16:21:50 -0600 (CST) X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [This is a copy of a message posted to comp.unix.bsd.freebsd.misc and comp.protocols.time.ntp] I'd just noticed one of the clocks on a newly deployed(*) box was about five minutes fast. The machine is a Pentium 200 with lots of RAM, within direct (ethernet) reachability of a Stratum 2 NTP server. The machine is running FreeBSD 3.0R, with securemode set to 2. The machine uses ntpdate to set its time upon boot, and then runs xntpd to maintain sync. It apparently ran into problems a week or two after booting. Log messages follow. Dec 21 23:14:24 nishaya xntpd[137]: xntpd version=3.4e (beta multicast); Sat Oct 17 16:05:15 GMT 1998 (1) Dec 21 23:14:24 nishaya xntpd[137]: tickadj = 5, tick = 10000, tvu_maxslew = 495 Dec 21 23:14:24 nishaya xntpd[137]: using xntpd phase-lock loop Dec 22 04:30:06 nishaya xntpd[137]: Previous time adjustment didn't complete Dec 31 19:07:33 nishaya xntpd[137]: Can't set time of day: Operation not permitted Dec 31 19:07:33 nishaya xntpd[137]: time reset (step) -1.003854 s Dec 31 19:11:26 nishaya xntpd[137]: Previous time adjustment didn't complete Dec 31 19:12:37 nishaya xntpd[137]: Can't set time of day: Operation not permitted Dec 31 19:12:37 nishaya xntpd[137]: time reset (step) -1.154277 s Dec 31 19:17:09 nishaya xntpd[137]: Can't set time of day: Operation not permitted [...bla bla bla...] Jan 6 15:07:01 nishaya xntpd[137]: Can't set time of day: Operation not permitted Jan 6 15:07:01 nishaya xntpd[137]: time reset (step) -264.384161 s This seems to suspiciously coincide with the leap second announced last summer (time here is CST). I am guessing that the clock suddenly found itself one second fast, due to the 61 seconds in the minute where the leap second happened, and NTP tried to compensate by stepping back a second. This failed because FreeBSD does not allow this in securemode (a fabulous change, guys!!!) and NTP apparently did not slew the clock backwards to compensate. I'm posting this to both comp.unix.bsd.freebsd.misc, for comments, and to comp.protocols.time.ntp, so that someone can tell me why I'm wrong about this. :-) Either way, ideally, I am not sure why NTP would fail to adjust-via-slew for a second or two. :-( With the lack of tickadj in 3.0R, it looks like my options are to reboot :-( or to try to fiddle around with the drift file in an attempt to mess with NTP's mind. ... JG (*) recycled, actually GETTIMEOFDAY(2) FreeBSD System Calls Manual GETTIMEOFDAY(2) NAME gettimeofday, settimeofday - get/set date and time SYNOPSIS #include int gettimeofday(struct timeval *tp, struct timezone *tzp) int settimeofday(const struct timeval *tp, const struct timezone *tzp) DESCRIPTION [...] Only the super-user may set the time of day or time zone. If the system is running in secure mode (see init(8)), the time may only be advanced. This limitation is imposed to prevent a malicious super-user from setting arbitrary time stamps on files. The system time can still be adjusted backwards using the adjtime(2) system call even when the system is se- cure. [...] ... Joe ------------------------------------------------------------------------------- Joe Greco - Systems Administrator jgreco@ns.sol.net Solaria Public Access UNIX - Milwaukee, WI 414/342-4847 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message