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.8p8 was released on 02 June 2016 and addresses 1 high- and 4 low-severity security issues, 4 bugfixes, and contains other improvements over 4.2.8p7.

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

First Last Prev Next    This bug is not in your last search results.
Bug 2718 - ntpd -n forks
: ntpd -n forks
Status: RESOLVED WORKSFORME
Product: ntp
Classification: Unclassified
Component: ntpd
: 4.2.8
: Macintosh MacOS X
: P5 normal
: ---
Assigned To: Harlan Stenn
:
:
:
:
  Show dependency tree / graph
 
Reported: 2014-12-30 01:47 UTC by xyzzy
Modified: 2014-12-30 05:14 UTC (History)
1 user (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description xyzzy 2014-12-30 01:47:08 UTC 
After building and installing ntp 4.2.8 I see two ntpd processes when ntpd
starts on my OS X 10.6.7 (Snow Leopard).  ntpd is launched as follows:

exec /usr/sbin/ntpd -c /private/etc/ntp-restrict.conf -n -g -p
/var/run/ntpd.pid -f /var/db/ntp.drift

Since -n is specified I would not expect ntpd to fork.  Yet the process list
indicates that the parent ntpd forks a child ntpd.  The child terminates after
a few minutes leaving only the parent running.

My ntp-restrict.conf referenced from the ntpd command looks as follows (deleted
comments for this post -- used dashed lines to make the code easier to see):

--------------------------------------------------------------
restrict default kod limited nomodify notrap nopeer noquery
restrict -6 default kod limited nomodify notrap nopeer noquery
restrict 127.0.0.1
restrict -6 ::1
includefile /private/etc/ntp.conf
rlimit memlock 0
--------------------------------------------------------------

/private/etc/ntp.conf looks like,

--------------------------------------------------------------
server time.apple.com
--------------------------------------------------------------

Finally the system.log has the following when ntpd is launched:

--------------------------------------------------------------
Dec 29 13:17:10 xxxx ntpd[13300]: ntpd 4.2.8p1-beta2@1.3265-o Mon Dec 29
20:06:09 UTC 2014 (5): Starting
Dec 29 13:17:10 xxxx org.ntp.ntpd[13300]: 29 Dec 13:17:10 ntpd[13300]: ntpd
4.2.8p1-beta2@1.3265-o Mon Dec 29 20:06:09 UTC 2014 (5): Starting
Dec 29 13:17:10 xxxx org.ntp.ntpd[13300]: 29 Dec 13:17:10 ntpd[13300]: Command
line: /usr/sbin/ntpd -c /private/etc/ntp-restrict.conf -n -g -p
/var/run/ntpd.pid -f /var/db/ntp.drift
Dec 29 13:17:10 xxxx ntpd[13300]: proto: fuzz beneath 0.077 usec
Dec 29 13:17:10 xxxx org.ntp.ntpd[13300]: 29 Dec 13:17:10 ntpd[13300]: proto:
precision = 1.000 usec (-20)
Dec 29 13:17:10 xxxx org.ntp.ntpd[13300]: 29 Dec 13:17:10 ntpd[13300]: proto:
fuzz beneath 0.077 usec
Dec 29 13:17:10 xxxx org.ntp.ntpd[13300]: 29 Dec 13:17:10 ntpd[13300]: Listen
and drop on 0 v6wildcard [::]:123
Dec 29 13:17:10 xxxx org.ntp.ntpd[13300]: 29 Dec 13:17:10 ntpd[13300]: Listen
and drop on 1 v4wildcard 0.0.0.0:123
Dec 29 13:17:10 xxxx org.ntp.ntpd[13300]: 29 Dec 13:17:10 ntpd[13300]: Listen
normally on 2 lo0 [::1]:123
Dec 29 13:17:10 xxxx org.ntp.ntpd[13300]: 29 Dec 13:17:10 ntpd[13300]: Listen
normally on 3 lo0 [fe80::1%1]:123
Dec 29 13:17:10 xxxx ntpd[13300]: setsockopt IPV6_MULTICAST_IF 0 for fe80::1%1
fails: Can't assign requested address
Dec 29 13:17:10 xxxx org.ntp.ntpd[13300]: 29 Dec 13:17:10 ntpd[13300]:
setsockopt IPV6_MULTICAST_IF 0 for fe80::1%1 fails: Can't assign requested
address
Dec 29 13:17:10 xxxx org.ntp.ntpd[13300]: 29 Dec 13:17:10 ntpd[13300]: Listen
normally on 4 lo0 127.0.0.1:123
Dec 29 13:17:10 xxxx org.ntp.ntpd[13300]: 29 Dec 13:17:10 ntpd[13300]: Listen
normally on 5 en0 192.168.1.68:123
Dec 29 13:17:10 xxxx ntpd[13300]: setsockopt IPV6_MULTICAST_IF 0 for
fe80::ea06:88ff:fecd:4ae9%4 fails: Can't assign requested address
Dec 29 13:17:10 xxxx org.ntp.ntpd[13300]: 29 Dec 13:17:10 ntpd[13300]: Listen
normally on 6 en0 [fe80::ea06:88ff:fecd:4ae9%4]:123
Dec 29 13:17:10 xxxx org.ntp.ntpd[13300]: 29 Dec 13:17:10 ntpd[13300]:
setsockopt IPV6_MULTICAST_IF 0 for fe80::ea06:88ff:fecd:4ae9%4 fails: Can't
assign requested address
Dec 29 13:17:10 xxxx org.ntp.ntpd[13300]: 29 Dec 13:17:10 ntpd[13300]:
Listening on routing socket on fd #27 for interface updates
--------------------------------------------------------------

Is there anything in that log that would indicate the cause of the fork?  If
not why is the ntpd -n option not having the effect I expected?  Or is all this
normal and I shouldn't worry or care about it?

---

And while off topic I guess, what are those "setsockopt IPV6_MULTICAST_IF..."
messages in the log anyway? :-)  Is there a way to get rid of them?
Comment 1 xyzzy 2014-12-30 01:52:20 UTC 
Forgot to change the first platform field to "Macintosh".
Comment 2 Harlan Stenn 2014-12-30 03:55:33 UTC 
You're seeing the 2nd ntpd process because that's where the DNS resolution of
time.apple.com is being done.  That mechanism is independent of the -n switch.

You are seeing messages like:

 setsockopt IPV6_MULTICAST_IF 0 for fe80::1%1 fails: Can't assign requested
address

because we're iterating thru the various network interfaces to set them up for
use by NTP and on those 3 the setsockopt() call to set up IPv6 multicast, and
the things we're trying to do are failing.

See line 1010 of ntp_io.c.

I don't know if that is an indication of a problem with the code or with your
system, but until we get feedback from somebody who understands IPV6 Multicast
on your OS the messages will serve as a notice that there's something that
needs some attention.  This may or may not be related to bug 629.

This last item is not in the scope of this bug report, so I'm marking this
issue as RESOLVED/WORKSFORME.  Please let me know if I missed anything :)
Comment 3 xyzzy 2014-12-30 04:18:00 UTC 
Thanks for the explanation.  Sounds good to me :-)  

Was this fork ntpd change done in some ntp version beyond 4.2.4 (that's the
version in Snow Leopard 10.6.7 from Apple)?  The only reason I asked in the
first place was because I don't see this behavior on my system with ntpd 4.2.4.
 In fact I don't see on a friend's OS X 10.10 which includes the latest Apple
security update but apparently still reports ntpd is version 4.2.6 (looks like
Apple did their own security fixes, that, or forgot to update their version
number).  So did this fork change occur sometime after 4.2.6?  

And I agree with you to make this as RESOLVED/WORKSFORME since I did say that
the setsockopt stuff was "off topic" to the main question.

Thanks.
Comment 4 Harlan Stenn 2014-12-30 05:14:42 UTC 
> --- Comment #3 from xyzzy <anonymous42a@gmail.com> 2014-12-30 04:18:00 UTC --
> -
> Thanks for the explanation.  Sounds good to me :-)  

Good, thanks!

> Was this fork ntpd change done in some ntp version beyond 4.2.4
> (that's the version in Snow Leopard 10.6.7 from Apple)?  The only
> reason I asked in the first place was because I don't see this
> behavior on my system with ntpd 4.2.4.

We've always done DNS lookups in a fork, at least as best as I can
remember (I see it in ntp-4.1.0, for example).

>  In fact I don't see on a friend's OS X 10.10 which includes the
>  latest Apple security update but apparently still reports ntpd is
>  version 4.2.6 (looks like Apple did their own security fixes, that,
>  or forgot to update their version number).  So did this fork change
>  occur sometime after 4.2.6?

No idea.  I'm hot sure what changes Apple has made to their codebase.

> And I agree with you to make this as RESOLVED/WORKSFORME since I did
> say that the setsockopt stuff was "off topic" to the main question.

Cool, thanks!

H
First Last Prev Next    This bug is not in your last search results.