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

Paul Vixie paul at
Sat Feb 19 10:12:21 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
> strength.

fwiw, i agree w/ dave for the most part.  i note however that the unix way
of doing things (write/edit the config file, HUP a daemon, look at logfiles)
wasn't new with unix and it's kind of old now.  appliance bundlers of ntp,
bind, sendmail, and other OSS implementations of lifeline internet protocols
are not competing against unix -- they're competing against mswindows.  that
means they have to have a GUI.  right now their GUI reads/parses our config
files, offer up a GUI editor to whatever they found there, rewrites our
config files, and then hopes that the operator will check the logs to find
out what happened.  this is self-marginalizing behaviour.

so while i agree that trying to teach every protocol its own management layer
and then securing all of those is a fool's errand, i do not love config files
per se.  i'd like very much for ntp and bind and the other OSS implementations
of lifeline internet protocols to learn how to read config out of sql, ldap,
or $TBD, including incremental changes (*), and to use textual config files
as a last resort.

(*) this is the thing that harlan said he wanted that dave said he didn't
want, and i think it's closer to the heart of whatever disagreement remains.
killing and restarting a service is just as "passe" as a textual config file.
even if the end result is to "discard all state and begin at the top", which
dave says ntpd should do but harlan (and i) both hope ntpd can learn not to
do, it should be possible to change your config without changing your getpid(),
if for no other reason than that you might have an open session to some kind
of juniper-xmlscript-like console somewhere, and churning it makes a light
blink for no reason.

More information about the hackers mailing list