Date: Tue, 15 Jan 2002 15:03:42 -0500 (EST) From: FreeBSD@jovi.net To: freebsd-questions@FreeBSD.ORG Cc: FreeBSD@jovi.net, freebsd-arch@FreeBSD.ORG Subject: Re: kern/33904: secure mode bug Message-ID: <200201152003.g0FK3gb04767@grant.org> In-Reply-To: <CD13C334-09D5-11D6-8ED3-003065D5E9A4@infospace.com> (message from William Carrel on Tue, 15 Jan 2002 08:34:52 -0800) References: <CD13C334-09D5-11D6-8ED3-003065D5E9A4@infospace.com>
next in thread | previous in thread | raw e-mail | index | archive | help
It would help to document or fix date/ntpdate/ntpd/...
to warn of this "clock clamp" trouble or better yet
fix settimeofday to return EPERM instead of trying
to second-guess the intent of the programmer.
If not, settimeofday documentation must clarify this silent lossage
of setting a time other than what the calling program specified.
If write were to sometimes read rather than report EROFS
we'd expect that to be prominently and frequently documented!
Cheers
--Devon
/"\
\ / ASCII Ribbon Campaign
X Help Cure HTML Mail
/ \
PS: Yes, I read everything you quote before writing the initial bug report.
While I was flogging ntpdate and tailing logs it was clear the kernel
was clamping the clock but it offered no clue as to how or why.
The fact that date/ntpdate/ntpd/... were silently failing was
especially confusing. Silent failure can never be tolerated.
Yes, my hardware has major clock drift. I am in the real world, I
have more things to do than read up on every ill considered experiment
that breaks stuff which used to work. I enabled no secure level,
whoever configured the box did. Time was silently failing.
At the very least, document trouble if you won't fix it.
Date: Tue, 15 Jan 2002 08:34:52 -0800
Reply-To: freebsd-questions@FreeBSD.ORG
From: William Carrel <william.carrel@infospace.com>
[This probably belongs to -questions.]
On Tuesday, January 15, 2002, at 07:26 AM, FreeBSD@jovi.net wrote:
> Thanks for your reply.
> I suggest escalating the trouble.
> Correct time is mission-critical on many systems
> and this is an issue of unreliable service under FreeBSD.
No. This is an issue of a user not reading the appropriate
documentation before changing the securelevel and then being surprised
when it exhibits exactly the behavior documented there. There are good
reasons why time changes are clamped to one second under that
securelevel.
> A settimeofday other than that programmed is worse than doing nothing.
> Three orders of magnitude is a complete failure by every reasonable
> standard.
> Breaking date, ntpdate, ntpd, ... is a reliable indication of severe
> failure.
> These programs now need rewriting to operate reliably.
No. You need to run sync your clock before raising securelevel. Or
keep your securelevel down below two. Of course, I'm sure you read this
part of init(8)'s man page:
2 Highly secure mode - same as secure mode, plus disks may not
be
opened for writing (except by mount(2)) whether mounted or
not.
This level precludes tampering with filesystems by unmounting
them,
but also inhibits running newfs(8) while the system is
multi-user.
In addition, kernel time changes are restricted to less than
or
equal to one second. Attempts to change the time by more
than this
will log the message ``Time adjustment clamped to +1 second''.
If you sync before raising securelevel and then run ntpd, unless your
box has severe problems with clock drift (like NetBSD/mac68k
15mins/hour) it should stay in sync. Be sure not to adjust other knobs
like securelevel without knowing what you're doing and consulting the
appropriate manpages, it will save you lots of pain.
Modifying these things to return ETIMEADJCLAMPED or some such seems a
little silly, and would represent a pretty hairy delta into ntpd.
-- Andy
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200201152003.g0FK3gb04767>