[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
Sat Nov 21 10:19:50 UTC 2015


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

Juergen Perlinger <perlinger at ntp.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |CONFIRMED
                 CC|                            |perlinger at ntp.org
     Ever Confirmed|0                           |1

--- Comment #9 from Juergen Perlinger <perlinger at ntp.org> 2015-11-21 10:19:50 UTC ---
I finally found time to dig into this problem, and it is *not* a problem of
NTPD per se but a indeed a matter of providing the right jailed environment. In
short:

     >>> USING A ROOT JAIL WORKS <<<

I'm not sure about the race condition mentioned in comment #3, but the
name-resolving worker threads created after the root jail is in effect are
clearly affected.

I'm running 

Linux 3.19.0-26-generic #28-Ubuntu SMP Tue Aug 11 14:16:32 UTC 2015 x86_64
x86_64 x86_64 GNU/Linux

and I provided

rootfs=/var/chroot/ntp

if [ ! -x ${rootfs}/dev/urandom ]; then
    mknod ${rootfs}/dev/urandom c 1 9
fi

cp -av /etc/localtime  ${rootfs}/etc

cp -av /lib/x86_64-linux-gnu/libnss_files.so.2 ${rootfs}/lib
cp -av /lib/x86_64-linux-gnu/libnss_compat.so.2 ${rootfs}/lib
cp -av /lib/x86_64-linux-gnu/libnsl.so.1  ${rootfs}/lib
cp -av /lib/x86_64-linux-gnu/libnss_nis.so.2  ${rootfs}/lib

apart from all the other stuff you are surely aware of.

It took me some time with 'strace', capturing the file operations and comparing
the results from a 'free' and a 'jailed' process to find what's missing.

The really bad thing is that the solution is probably highly distribution
dependent, as it clearly depends on the dynamic resolver code in GLIBC.

A similar problem might exist under BSD.

I'll set this to 'confirmed' but don't assign it, since I'm not sure how to
proceed from here. In my books this is a matter of maintaining the packet for a
distribution. Just my 5c here.

Cheers,
  Pearly

-- 
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