|
Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com |
Re: Security Hole in Axent ESM
Jeffrey Hutzelman (jhutz+
cmu.edu)Mon, 31 Aug 1998 22:51:58 -0400
- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Theo de Raadt: "Re: nslookup issues"
- Previous message: Justin Priestley: "Bug in login"
- In reply to: Caskey L. Dickson: "Re: Security Hole in Axent ESM"
- Next in thread: Caskey L. Dickson: "Re: Security Hole in Axent ESM"
> Another, separate problem is the issue of arbitrary drift caused by > console messages. It is my understanding that some unices turn off all > interrupts when dumping messages to the console and as such can cause the > timer to miss a beat. Such is the reason for timed and many other > collaborative clock management daemons. > > I would propose a more subtle mechanism where the system could be told to > gain or lose a certain number of seconds, but with an inbuilt maximum rate > of change (say one second every minute). This would allow for gradual > corrections that are arbitrary on top of a system for guarding against > constant drift. "I need to make up 13 seconds." -> timetrim( 13 ). > > This could all be layered on top of the existing Linux adjtimex however I > don't know what the limits of it are (i.e. could you make a system gain an > hour every second). You would also need some method for re-setting the > time adjustment back to the 'no adjustment' adjustment when the desired > change has been made. Before you reinvent the wheel or try to change any kernel interfaces related to time synchronization, I'd suggest you take a look at http://www.eecis.udel.edu/~ntp, which includes a complete description of the Internet-standard Network Time Protocol and how it works, including a reference implementation. This is perhaps the single most important program that actually _uses_ those interfaces, and it uses them to do fairly complex corrections that allow the time to be readjusted while still being monotonically increasing. -- Jeffrey T. Hutzelman (N3NHS) <jhutz+cmu.edu> Systems Programmer School of Computer Science - Research Computing Facility Carnegie Mellon University - Pittsburgh, PA
- Next message: Theo de Raadt: "Re: nslookup issues"
- Previous message: Justin Priestley: "Bug in login"
- In reply to: Caskey L. Dickson: "Re: Security Hole in Axent ESM"
- Next in thread: Caskey L. Dickson: "Re: Security Hole in Axent ESM"