Config file format - (Was: [ntp:hackers] FreeBSD serial ports)

David L. Mills mills at
Sat Feb 19 10:00:20 PST 2005


No, no, a zillion time no. Linux is the best of the bad examples. Do NOT 
rewrite the configuration file under any circumstance in the galaxy. I 
have no problem if you want to create a temporary state file (ntp.drift 
is an example), but on restart read the read-only configuration file 
every time.

The more I think about it, the more I become unfriendly about remote 
configuration as a security pothole. Compare the cryptographic strength 
of Autokey and the current vulnerability of remote configuration to 
attack. Consistency requires remote configuration to have equivalent 


Harlan Stenn wrote:

>I want ntpd to be able to write a config file (the location of the file need
>not be the standard location) for 2 reasons:
>- it is a way to make it easy to "dump state", and I think it will help
>  debug the parsing code for the new config file format
>- I want it - I think it is neat
>If folks don't want to allow remote config it is trivial to disable it,
>using a number of methods.
>For remote/enbedded devices, it may also be easier to do a remote config
>then it is to "log in" to the device and send a HUP signal (assuming, of
>course, that a) one can log in to the device, and b) the underlying OS
>supports sending a HUP signal).
>One of the reasons for allowing remote config is that ntpd maintains
>ongoing "state" information, and a full shutdown/restart can be Bad.
>Therefore, sometimes it may be a useful/good idea to allow remote 
>configuration changes.

More information about the hackers mailing list