This is the mail archive of the
mailing list for the glibc project.
[Bug network/984] Respond to changed resolv.conf in gethostbyname
- From: "carlos at redhat dot com" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Mon, 15 Aug 2016 20:03:01 +0000
- Subject: [Bug network/984] Respond to changed resolv.conf in gethostbyname
- Auto-submitted: auto-generated
- References: <firstname.lastname@example.org/bugzilla/>
--- Comment #16 from Carlos O'Donell <carlos at redhat dot com> ---
(In reply to Karl from comment #15)
> Any update?
> This bug is now 11 years old and injects false notions into posiz compliant
> Caching the resolver should be avoided at all costs. There are methods to
> cache the name lookups which should be used, but caching the resolver
> results in bad results with Network Manager (installed by default by Red
> Hat) and any modifications to the resolv.conf name servers.
> The only way to address this currently is to reboot the server anytime the
> resolver is modified. This is not practical and, again, Network Manager will
> modify it after boot. I've already proven that nscd and sssd do not address
> this break.
> There's also a very real exploit here. A hacker could gain the ability to
> modify the resolv.conf, restart apache, sendmail, or other app which is
> caching the resolver information, place back the original resolv.conf and
> now use their name servers to route web or smtp traffic to their sites.
There is some consensus that glibc should be changed to match the debian-glibc
behaviour which checks for changes in /etc/resolv.conf.
The problem as noted in comment 13 by Florian we need better test
infrastructure in glibc to test resolver changes. With that in mind I reviewed
Florian's chroot-based test for resolver changes here:
Thus I think we're making some progress here.
You are receiving this mail because:
You are on the CC list for the bug.