[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 Feb 5 09:13:47 UTC 2016


--- Comment #21 from Reinhard Max <max at suse.com> 2016-02-05 09:13:47 UTC ---
Whoops, haven't you seen that I already revoked my suggestion to use
__nss_disable_nscd() last Tuesday in a reply to Harlan's mail with you in Cc?
I am repeating it here for the records:

---- snip ---

please put further work on my proposed patch on hold for now.

"Warming up" NSS like this initially sounded like a clever trick, but after
talking to a few people here it doesn't seem to be feasable anymore with
using an internal symbol that might change its signature or even disappear
at any time without notice being only the tip of the iceberg.

I'll investigate this some more and will soon get back to you.
--- snap ---

An additional problem is, that we would still have to copy the config files
that the loaded NSS modules are using, and make sure that they can
(re)establish the communication channels they need, where applicable. All in
all, __nss_disable_nscd() is just shifting the problem rather than solving it.
Sorry for the noise.

Meanwhile I've tried to set up the chroot environment in a way so that ntpd can
access nscd (which would then be mandatory for ntpd on glibc systems), but that
also didn't work out. It works fine if nscd is kept running, but if it gets
restarted and ntpd tries to do a name lookup while it is down, glibc falls back
to doing the name lookups itself (which it can't because the libs are missing)
and only tries to reconnect to nscd after 100 (hardcoded!) lookups.

Currently it looks to me like the only practicable way will be a proxy for host
and service name lookups that runs outside of the chroot. I'll do some more
research to see if something like this already exists or if we have to do it on
our own.

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