r16 - 2015-02-18 - 13:19:06 - TlHackqueYou are here: NTP >  Dev Web > DevelopmentIssues > NtpPathNames
NTP users are strongly urged to take immediate action to ensure that their NTP daemons are not susceptible to being used in distributed denial-of-service (DDoS) attacks. Please also take this opportunity to defeat denial-of-service attacks by implementing Ingress and Egress filtering through BCP38.

ntp-4.2.8p12 was released on 14 August 2018. It addresses 1 low-/medium-severity security issue in ntpd, 1 low-severity security issue in ntpq and ntpdc, and provides 27 non-security bugfixes and 4 other improvements over 4.2.8p11.

Please see the NTP Security Notice for vulnerability and mitigation details.

Are you using Autokey in production? If so, please contact Harlan - he's got some questions for you.

NTP Path Names

NTP has traditionally used a number of path names that, with the benefit of hindsight, would be different.

Whenever we have made the attempt to "fix" these issues, the pushback has been hard. So we have tried to come up with ways to satisfy both types of users.

Usually I have tried to keep the default paths the traditional ones. This has proven to be difficult. I'm now wondering if it might be better to have the default paths be the contemporary choices and document the way to get the software to install into the traditional locations.

What Traditional Desired Current solution or Notes
ntpd, ntpdsim, ntpdate,
ntpq, ntpdc, sntp=
bindir Depends on the OS Handled by =sntp/loc/ files.
ntp.conf, ntp.keys,
ntp.audio, ntp.oncore*
/etc sysconfdir Will default to /etc
ntp.drift /etc ${localstatedir}/db/ntp/ No default; only used by example in the documentation
ntp.kod /var/db ${localstatedir}/db/ntp/ Currently used by sntp. ntpd does not yet have a 'persistent state' file for KOD.
NTP statistics /var/NTP ${localstatedir}/log/ntp/ '-DNTP_VAR="/var/NTP/"'

In bug_small.png Bug #382 noted below, comment #8, it says:

I'm thinking that it might be much easier to use a new variable, ntpconfdir, and it would legacy-default to /etc, and we can find a way to add ntpconfdir=etc to the sntp/loc/ files so different OSes could override this (I'd like to see the list of what the various OSes use for this now), and it would also allow local admins to override this value by supplying --ntpconfdir=XXX on the configure line.

The driftfile actually has no default value in the code. The only reason I can see to provide it is for the documentation, and it may be easier to just tell folks to look in the config file for the location of the drift file.

The biggest reason for the location of the statistics might also be for the documentation. I know we won't create a non-existing statistics directory.

Due to the hackery involved, the solution implemented in 4.2.7pXXX (not yet - certainly after p480) is to add lines like:

ntpconfdir,VAR,/etc
ntpdriftdir,VAR,/etc
ntpstatsdir,VAR,/var/NTP

to sntp/loc/legacy, and for newer installations:

ntpconfdir,VAR,/etc
ntpdriftdir,VAR,${localstatedir}/db/ntp
ntpstatsdir,VAR,${localstatedir}/log/ntp

Of course, any paths may be used.

sysconfdir used to be difficult - before, we could not easily see if we're using the default value or one specified from the configure invocation. One solution to this would be to use ntpconfdir instead of sysconfdir, and we also need to consider if we should handle this by augmenting the information in the sntp/loc/ files. But now, we do have a way to see if the traditional autoconf directory variables have been overridden:

     test "$prefix" = NONE && prefix=/usr/share/local/gnu
     test "$exec_prefix" = NONE && exec_prefix=/usr/local/gnu
     test "$sharedstatedir" = '${prefix}/com' && sharedstatedir=/var
     test "$localstatedir" = '${prefix}/var' && localstatedir=/var

Related Topics: bug_small.png Bug #382 bug_small.png Bug #594 bug_small.png Bug #643 bug_small.png Bug #1056, bug_small.png Bug #2461

  • SNTP is a tear-off, and therefore the information needs to be in that subdir so it's also available in the event somebody only wants to distribute the SNTP code. We expect sntp to be part of the distribution. We also expect that some folks will only want SNTP. If somebody chooses to not install sntp that's their choice, but we still need it in the tree.

-- HarlanStenn - 03 Dec 2014

  • Since this involves much more than sntp, wouldn't it be advisable to move the files and related scripts up a directory level so that it doesn't appear to be sntp-specific?

There exist OS distributions that don't distribute (and probably don't care about) sntp.

-- BruceLilly - 03 Dec 2014

Whatever the mechanics, ntp violates the principle of least surprise: --prefix=/opt should cause ntpd to look for ntp.conf in /opt/etc, but does not.

Given the history and repackagers who rely on current behavior, I suppose a solution would be to document that one uses configure to move the default config file, with

"CPPFLAGS=CONFIGFILE=\$(PREFIX)/etc/ntp.conf"

or some such.

If that advice showed up from configure --help, I guess I['d be less unhappy.

Oddly enough, the default KEY file does seem to obey --prefix, so ntp is inconsistent.

Another thought:

What about adding --with-config-obeys-prefix, defaulting to '--without' ?

Then everyone can have what they want. To get standard behavior, add --with-config-obeys-prefix to your configure line; then everything works per the 'standard', including cross-builds and other wierd cases.

For compatible behavior, specify --without-config-obeys-prefix. Document that folks who want to continue to rely on the 'traditional' behavior should add this to their configure commands. Then in 5 years or so, the default can be flipped. :-)

Once the C code knows to listen to configure, it becomes simpler, and configure can handle sorting out the options.

-- TlHackque - 16 Feb 2015

 
Edit | WYSIWYG | Attach | Printable | Raw View | Backlinks: Web, All Webs | History: r16 < r15 < r14 < r13 < r12 | More topic actions
 
SSL security by CAcert
Get the CAcert Root Certificate
This site is powered by the TWiki collaboration platform
IPv6 Ready
Copyright & 1999-2018 by the contributing authors. All material on this collaboration platform is the property of the contributing authors. Ideas, requests, problems regarding the site? Send feedback