Date: Fri, 8 Jan 1999 16:21:50 -0600 (CST) From: Joe Greco <jgreco@solaria.sol.net> To: current@FreeBSD.ORG Subject: 3.0R and NTP, security changes in settimeofday Message-ID: <199901082221.QAA01047@aurora.sol.net>
next in thread | raw e-mail | index | archive | help
[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 <sys/time.h>
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199901082221.QAA01047>