Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
DescriptionJan Pokorný [poki]
2013-06-19 13:20:33 UTC
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
Comment 6Siddhesh Poyarekar
2015-03-11 16:48:16 UTC
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 8Zbigniew Jędrzejewski-Szmek
2016-02-03 15:30:18 UTC
nss-myhostname solves this nicely. Hopefully it will become standard in Fedora, solving this problem.
Comment 9Jan Pokorný [poki]
2016-02-10 11:13:22 UTC
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)
192.0.2.1 localhost
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.