Red Hat Bugzilla – Bug 975856
[RFC] preserve special meaning of localhost vs /etc/hosts?
Last modified: 2017-07-28 07:18:38 EDT
Note: this is based on what I ran into on RHEL 5 so it doesn't necessarily
reflect the current state. However RHEL 7 may be good opportunity to
adjust glibc name resolution as per current directions (see below).
Thing is that, for example, if the very first definition of localhost
in /etc/hosts points to the IP address as visible externally (or even
any arbitrary address), some implicit assumptions may be broken.
[ I am not discussing how sane is mangle with localhost in /etc/hosts,
only about possibilities to do so. Also, we could talk about
security considerations, but the file in question is root-owned... ]
For instance, stunnel expects the local side to be exactly 127.0.0.1
(or at least, is not misguided by such /etc/hosts file) and reacts in
an unexpected way externally when it cannot connect to this internal side
as a consequence of original service configured to be served at
'localhost' (even if coincidentally, the service runs OK). Such observed
'localhost' fragility is one of the reasons that made me file this bug
to reconsider 'localhost' handling.
The other and more substantial reason is that in relation to my
observation, I've found [RFC 6761], particularly section 6.3 that discusses
how 'localhost' SHOULD/MAY be special. I think it provides a reasonable
way out of this fragility. It's still only a 'proposed standard', however
making an explicit agreement on 'localhost' seems natural for a forseeable
future (and future-proofing is what this bug asks to be discussed).
[RFC 6761] http://tools.ietf.org/html/rfc6761
I suppose this is something we could possibly do in glibc, i.e. assume localhost.* to always mean the loopback interface and never use any nss plugin to resolve it, let alone use DNS. It would also be considerably faster since it would short-circuit the entire nss plugin load and traverse loop and instantly return a result.
However, I wonder if it is worth the effort invested to protect the user from a deliberately silly configuration to assign localhost to a non-loopback address. In any case, it would be safer to take this up as an action item in Fedora/upstream first and not in RHEL.
nss-myhostname solves this nicely. Hopefully it will become standard in Fedora, solving this problem.
For reference, recent traffic was due to the reference in the thread wrt.
nss_myhostname at the Fedora devel ML:
The use of nss-myhostname is becoming standard, but we still need to solve bug 1319285 to prevent errors in cases where the name server is transiently unreachable.
Therefore I'm moving this out to rhel-7.5 for consideration.
If you add (for example)
to /etc/hosts, this will break applications which assume that localhost is 127.0.0.1. I do not think we have to hard-code localhost inside NSS (or nss_files). System administrators just need to be aware of the fact that putting garbage into /etc/hosts can break the system. Maybe we can add a comment to /etc/hosts that warns about such consequences, but /etc/hosts is not shipped by glibc, so a bug against the setup package would be needed for this change.
nss_myhostname in its current version does not help because it is at the end of the search path.