Bug 975856 - [RFC] preserve special meaning of localhost vs /etc/hosts?
[RFC] preserve special meaning of localhost vs /etc/hosts?
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: glibc (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: rc
: ---
Assigned To: Florian Weimer
Depends On: 1319285
Blocks: 1110700
  Show dependency treegraph
Reported: 2013-06-19 09:20 EDT by Jan Pokorný
Modified: 2017-07-28 07:18 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2017-07-28 07:18:38 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Jan Pokorný 2013-06-19 09:20:33 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
(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
Comment 6 Siddhesh Poyarekar 2015-03-11 12:48:16 EDT
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.
Comment 8 Zbigniew Jędrzejewski-Szmek 2016-02-03 10:30:18 EST
nss-myhostname solves this nicely. Hopefully it will become standard in Fedora, solving this problem.
Comment 9 Jan Pokorný 2016-02-10 06:13:22 EST
For reference, recent traffic was due to the reference in the thread wrt.
nss_myhostname at the Fedora devel ML:

Comment 10 Carlos O'Donell 2016-11-28 08:53:40 EST
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.
Comment 12 Florian Weimer 2017-07-28 07:18:38 EDT
If you add (for example) localhost

to /etc/hosts, this will break applications which assume that localhost is  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.

Note You need to log in before you can comment on or make changes to this bug.