[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
Thu Feb 4 18:10:32 UTC 2016


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

--- Comment #20 from Juergen Perlinger <perlinger at ntp.org> 2016-02-04 18:10:32 UTC ---
(In reply to comment #19)
> Created attachment 1382 [details]
> Initial patch to use __nss_disable_nscd
> 
> Here's my first attempt to get __nss_disable_nscd in.
> 
> After some quick smoke tests it appears to work, but still needs some polishing
> in (at least) the following areas:
> 
> 1. Proper addition of -ldl to configure/make/

AFAIK Harlan is working on this... I just butchered my Makefile until this
works.

> 2. Find the right place to call my_nss_warmup().

I put it currently immediately behind warming up the threading, and it works
like a charm, but...

> 3. Only call my_nss_warmup() if chrooting is actually being requested.

... doing it after the command line args are processed and chroot() is clearly
required will be better, indeed.

> 4. Add some logging.

Not sure if logging success makes much sense here (unless on a level like info
or notice) but failing should be logged as error.

> 
> BTW, I went for dlopen() rather than adding a prototype for
> __nss_disable_nscd() and calling it directly, because RPM by default actively
> prevents the installation of packages which contain binaries that are linked to
> private glibc symbols.

Which has the additional benefit that it can actually fail to resolve the
symbol without crashing the linker step. OTOH, if really needed we should log
that this step failed and trouble is to be expected. As mentioned above.

I put the chroot() step immediately after preprocessing the command line (but
after *resolving* any user:group spec), as this should definitely put a clamp
on any issues with races between thread creation and the chroot().

The downside is that all special files (/dev/random, /dev/null, /dev/ttyXX and
the clock devices) must be cloned into the root jail. But when properly done it
seems to work quite well.

I continue to work on the implementation. Reinhard, do you have access to
PSP.NTP.ORG, or should I roll a tarball on my support user page for you when I
think I'm ready to push my changes? (Assuming that you're willing to try out
what I created... but this shortcut has helped before in ironing out wrinkles
before they hit a release.)

-- 
Configure bugmail: https://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