From owner-freebsd-questions Tue Jan 15 12: 3:52 2002 Delivered-To: freebsd-questions@freebsd.org Received: from grant.org (grant.org [206.190.164.98]) by hub.freebsd.org (Postfix) with ESMTP id 4549237B417; Tue, 15 Jan 2002 12:03:43 -0800 (PST) Received: (from devon@localhost) by grant.org (8.11.6/8.11.6) id g0FK3gb04767; Tue, 15 Jan 2002 15:03:42 -0500 (EST) (envelope-from devon) Date: Tue, 15 Jan 2002 15:03:42 -0500 (EST) Message-Id: <200201152003.g0FK3gb04767@grant.org> From: FreeBSD@jovi.net To: freebsd-questions@FreeBSD.ORG Cc: FreeBSD@jovi.net, freebsd-arch@FreeBSD.ORG In-reply-to: (message from William Carrel on Tue, 15 Jan 2002 08:34:52 -0800) Subject: Re: kern/33904: secure mode bug References: Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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 [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-questions" in the body of the message