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

John Pettitt jpp at cloudview.com
Thu Feb 17 22:57:26 PST 2005



Harlan Stenn wrote:

>I see no reason to lose the remote config stuff - it is mode7 and is
>implementation-specific.
>
>I would also like to see the -c flag take a URL as an option, so one might
>say:
>
> ntpd -c file:///etc/ntp.conf  (current behavior)
>
> ntpd -c http://ntpconf.my.dom.ain  (get a conf file from a local server)
>
>
>I'd also like to have the ability for ntpd to write its current config file.
>
>Just some thoughts.
>
>H
>
I like the remote via url config idea - particularly for default
settings on distributions - it will allow for changes after the code
goes out and even smar replies best on where the server is calling from.
  The security issues will need some attention - particularly how to
protect against dns related attacks.

I still question in-band config - it's just a security hole waiting to
happen - every time a new feature gets added or changed there is a risk
that something gets broken.     Perhaps if there is a config from a url
then in-band config could be limited to a "re-load" command that just
causes the server to re-fetch it's out of-band config.   That would
effectivly be "dial back" security which would help.   I guess the idea
parsing complex commands from remote clients that send unknown fudge
argument to drivers that have kernel acces just scrares the crap out of me.

I'd also vote against programs writing to their config file, it's a bad
idea that also potentialy opens security holes.   If there is a simple
mechanism to allow ntpd to re-read it's config and a way for it to fetch
it from a designated url why does it need to write to it's local copy
(other than to cache what it fetched)?

John











More information about the hackers mailing list