This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug network/984] Respond to changed resolv.conf in gethostbyname

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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]