From owner-freebsd-hackers Thu Apr 1 17:30:32 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 10E2814F98 for ; Thu, 1 Apr 1999 17:30:31 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id RAA61810; Thu, 1 Apr 1999 17:30:10 -0800 (PST) (envelope-from dillon) Date: Thu, 1 Apr 1999 17:30:10 -0800 (PST) From: Matthew Dillon Message-Id: <199904020130.RAA61810@apollo.backplane.com> To: Nick Sayer Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Suggestion: loosen slightly securelevel>1 time change restriction References: <199904020033.QAA09981@medusa.kfu.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :At the moment, setting the time to any point in the past (that is, :if the delta being applied is negative) is not allowed if the securelevel :of the system is >1. : :The problem with this is that even if you run ntpdate at boot time, :xntpd can occasionally want to make small negative steps. : :I suggest easing up slightly on the restriction. Say, negative steps of :more than a minute are disallowed. It would seem to me that this would :let xntpd operate correctly in most cases while still denying the :opportunity for serious mischief to hackers desiring to wreak havoc :with time warps. : :Comments? We should remove the securelevel code that prevents the date from being set backwards. It's stupid code and doesn't work anyway... you can set the date forward enough times to wrap it. Also consider the fact that Kerberos will fail of the time isn't synchronized between machines and that NFS and many other subsystems will do weird things when the time is out of sync between machines. The 'protection' that securelevel is giving us, in regards to the time, is zip. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message