[ntp:hackers] NTP Development Snapshot 4.2.5p208 Released

Dave Hart davehart at gmail.com
Sun Aug 30 17:44:01 UTC 2009


On Sun, Aug 30, 2009 at 4:45 PM, Brian Utterback wrote:
> Overwriting the existing file is something that is highly dangerous and
> probably ought not to be allowed at all and to make it so simple to do by
> mistake is just not a good design.

For some people, overwriting the existing configuration file is the
only option that's interesting, as they would like to delegate ntpd
administration to someone who does not have any other access to the
host to replace files manually.  Without a shorthand for the startup
configuration file path, someone intending to replace it but without
access to the host would have to know or guess the startup
configuration filename.

> There are two things to consider that make this doubly dangerous. One, ntpq
> remembers your key entries after they are entered. Two, saveconfig does not
> validate its flags.

If you have an idea for better validation of arguments, please share.

> So, if you are in a ntpq session and have already
> entered the proper key, it will not ask you again when you run saveconfig.
> And if you happen to type
>
> "saveconfig . /conffile"
>
> instead of
>
> "saveconfig ./conffile"
>
> then you have just overwritten the origiunal ntp.conf file.

I am not sure why you'd be trying to write to ntpd's current directory
rather than a specified path.  Assuming there's a good reason, why
would you include "./" when leaving it off is equivalent?  We could
discourage this habit by rejecting saveconfig arguments beginning with
"." aside from "." alone.

> If you simply have to have this feature, I would prefer that there was an
> "enable confoverwrite" option that could not be changed remotely and
> defaults to disabled.

I don't have to have this feature.  I was thinking of Steve's
delegated ntpd administrator case and "." seemed a logical invalid
filename to use for the purpose.  I chafe at the concept of
special-case disabling of remote management of any configuration file
knob.  If we did have an "enable confoverwrite" or "enable
saveconfigoverwrite" knob to prevent overwriting the startup file or
any file, respectively, and it defaulted to off, why shouldn't the
operator be permitted to decide to enable it at runtime?  If you don't
want remote management, don't configure authentication to enable it,
or use "restrict ... nomodify".

> During testing, I also noticed that the config file that saveconfig saves
> does not include "includefile" directives. This makes it even worse, since
> the resulting config file is not functionally equivalent to the existing
> file.

But does it include the directives pulled from included files?  If so,
it's working as designed.  It is not supposed to spit out the
identical text that was fed in, but it is supposed to spit out a
functional equivalent.

Cheers,
Dave Hart


More information about the hackers mailing list