From owner-freebsd-arch Tue Jan 15 8:34:41 2002 Delivered-To: freebsd-arch@freebsd.org Received: from glenfiddich.infospace.com (mail1.infospace.com [206.29.197.33]) by hub.freebsd.org (Postfix) with SMTP id 15D4E37B41C for ; Tue, 15 Jan 2002 08:34:32 -0800 (PST) Received: (qmail 2400 invoked from network); 15 Jan 2002 16:34:30 -0000 Received: from unknown (HELO stoli.inspinc.ad) (206.29.197.190) by mail1.infospace.com with SMTP; 15 Jan 2002 16:34:30 -0000 Received: (qmail 29077 invoked from network); 15 Jan 2002 16:34:30 -0000 Received: from gasket.inspinc.ad (HELO irishbreakfast.carrel.org) ([10.99.32.118]) (envelope-sender ) by stoli.inspinc.ad (qmail-ldap-1.03) with SMTP for ; 15 Jan 2002 16:34:30 -0000 Date: Tue, 15 Jan 2002 08:34:52 -0800 Reply-To: freebsd-questions@FreeBSD.ORG Mime-Version: 1.0 (Apple Message framework v480) Cc: freebsd-questions@FreeBSD.ORG Message-Id: In-Reply-To: <200201151526.g0FFQFX02180@grant.org> Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: Re: kern/33904: secure mode bug From: William Carrel Content-Transfer-Encoding: 7bit To: FreeBSD@jovi.net X-Mailer: Apple Mail (2.480) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG [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