[ntp:bugs] [Bug 1503] New: enabling of monitor for "restrict ... limited" subtly wrong
Dave Hart via the NTP Bugzilla
bugzilla at ntp.org
Tue Mar 2 02:58:43 UTC 2010
Summary: enabling of monitor for "restrict ... limited" subtly
OS/Version: Windows NT
AssignedTo: hart at ntp.org
ReportedBy: hart at ntp.org
CC: bugs at lists.ntp.org
When IPv6 support was added to ntpd, the approach taken for the ntp_restrict.c
file was basically to duplicate every global variable and function into IPv4 and
IPv6 variants. In the process, a reference count used to light up the MRU list
via mon_start() and shut it down via mon_stop() when any "restrict ... limited"
are in effect was erroneously duplicated as well.
There should be a single reference count for "restrict ... limited" entries on
either v4 or v6 restrict lists. There is no reason to count them separately,
and in fact it's wrong. Imagine you have:
restrict default limited
That ends up as an entry on each of the v4 and v6 lists, for addresses 0.0.0.0
and ::, and bumps both v4 and v6 reference counts. Now suppose you at runtime
ntpq -c ":config restrict ::"
That modifies the v6 default restriction to no longer have RES_LIMITED. In the
process, the v6 reference count goes to zero and mon_stop() is called, yet there
are still RES_LIMITED restrictions active that can not be enforced unless the
MRU list is enabled.
The fix is trivial, consolidating the two reference counts into one. I'm
tempted after a bit more testing to simply backport the latest ntp_restrict.c
and ntp_monitor.c to -stable, because there are a raft of improvements and I'd
rather not try to maintain the old code.
Dave Hart <hart at ntp.org>
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
More information about the bugs