Thanks to:
"McIntire, John" <john_mcintire@ti.com>
David Mitchell <davem@fdgroup.co.uk>
"DAVID,Anthony" <Anthony.DAVID@dewrsb.gov.au>
Roger Fujii <rmf@lookhere.com>
Jochen Bern <bern@penthesilea.uni-trier.de>
Kevin Sheehan {Consulting Poster Child} <kevin@joltin.com>
Dan Brown <brown@obscure.org>
Pete Alleman <Pete.Alleman@cctechnol.com>
Some people ask me about my security concerns running "xntpd":
> I happen to be setting up xntpd, what are some of the security issues
Simply, xntp is a big server running as root. That's a security issue at
its own :-).
I'm thinking about running xntp as a low privileged user, and to use a
small SUID root "helper" to set the system clock. Future relases of
"xntp" should use a similar approach.
Proposals:
* Use "date -a" in a cron script.
Since I have 1.8 seconds daily drift, I'd slowly forward the
clock a second every 12 hours. "ntpdate" finetunes the clock every
24 hours.
Problem: The core problem is not solved.
* Adjust the clock "physically", touching the harware.
Problem: Not an option!.
* Some models have PROM settings to control drift.
Problem: I canīt find any useful in my system. And you have a problem
with clock granularity. See last option.
* Use "xntpd", boy.
Submillisecond precision, and the daemon can be used as a clock
reference to other computers in the network.
Problem: God dawn!. Yet another process running as root!.
* Use the "tickadj" program included in "xntpd" package.
This is the real solution I was searching.
This program change the system "ticks" increment, to compensate
fast or slow hardware clocks. The real solution for anybody with a
consistent and large clock drift.
But my drift is fairly small. My clock "ticks" at 99.9979167Hz,
instead of the correct 100.0Hz. The system tick is 10000 microseconds,
and the correct value should be 10000.2083367.
Since "tick" can only be integer... If I use 10001, my clock would
drift more than now.
The solution seems to be to set "tick" to 10001 for 5 hours and to
10000 por 19 hours every day. Cron rules!.
(10001*5+10000*19)/24 = 10000.20833333333333333333
I'll adopt the last solution, until I drop my concerns about xntp
running as root...
>>>>> Original Question <<<<<
I have an Ultra 1 with a consistent system clock drift. That is, the
workstation "lose" nearly two second per day. That is, a minute by
month.
I'm running ntpdate using cron, each night, and the result is
approximately:
[...]
Oct 24 05:27:01 corinto ntpdate[1132]: adjust time server 150.214.94.5
offset 1.841432 sec
Oct 25 05:27:01 corinto ntpdate[18180]: adjust time server 150.214.94.5
offset 1.782236 sec
[...]
I know that I can run xntp daemon to keep the clock within millisecond
error, but I'm not interested in this solution from a security
perspective.
Is there any system parameter I can set to specify the clock drift in
order to the OS to correct it?. Something like the "/etc/ntp.drift" in
xntpd package, but native to OS.
I'm using Solaris 2.5.1.
--
Jesus Cea Avion _/_/ _/_/_/ _/_/_/
jcea@argo.es http://www.argo.es/~jcea/ _/_/ _/_/ _/_/ _/_/ _/_/
_/_/ _/_/ _/_/_/_/_/
PGP Key Available at KeyServ _/_/ _/_/ _/_/ _/_/ _/_/
"Things are not so easy" _/_/ _/_/ _/_/ _/_/ _/_/ _/_/
"My name is Dump, Core Dump" _/_/_/ _/_/_/ _/_/ _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:13:30 CDT