[ntp:security] [Bug 2960] upgrade to 4.2.8p4 causes FAIL at name resolution; error: ntpd[9881]: giving up resolving host clock.isc.org: Servname not supported for ai_socktype (-8)

bugzilla-daemon at ntp.org bugzilla-daemon at ntp.org
Fri Jan 29 10:58:56 UTC 2016


http://bugs.ntp.org/show_bug.cgi?id=2960

Reinhard Max <max at suse.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |IN_PROGRESS
         Resolution|WORKSFORME                  |

--- Comment #14 from Reinhard Max <max at suse.com> 2016-01-29 10:58:56 UTC ---
I am reopening this, because setting up the chroot environment correctly is
only one part of the problem.

The other one is ntpd's non-deterministic behaviour as to when the threads get
chrooted (see comment 3 no. 1.). The main program spawns several threads before
it calls chroot() not knowing at what state the threads will be when they get
moved into the chroot environment. I found this out when chroot sometimes
worked and sometimes not without changing the configuration in between.

I think that part is well within the scope of ntp and should get addressed.

It might even have security implications, e.g. when a user wants ntpd to use
some nss (or other runtime-loadable) libraries in the chroot environment that
are different from those in the main OS, but some thread loads them before it
gets chrooted and hence gets the wrong ones.

To solve this, either the main program should first chroot and then spawn the
other threads, or the threads that get started before chrooting should signal
to the main thread when they are ready for being chrooted and then wait until
it has happened.

-- 
Configure bugmail: http://bugs.ntp.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.


More information about the security mailing list