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.
Bug 975856 - [RFC] preserve special meaning of localhost vs /etc/hosts?
Summary: [RFC] preserve special meaning of localhost vs /etc/hosts?
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: glibc
Version: 7.0
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Florian Weimer
QA Contact: qe-baseos-tools-bugs
URL:
Whiteboard:
Depends On: 1319285
Blocks: 1110700
TreeView+ depends on / blocked
 
Reported: 2013-06-19 13:20 UTC by Jan Pokorný [poki]
Modified: 2017-07-28 11:18 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-07-28 11:18:38 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description Jan 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 6 Siddhesh 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 8 Zbigniew 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 9 Jan Pokorný [poki] 2016-02-10 11:13:22 UTC 
For reference, recent traffic was due to the reference in the thread wrt.
nss_myhostname at the Fedora devel ML:

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/UIRHNFGXQBOUOIBHUIFIK7U336V4W3N5/
Comment 10 Carlos O'Donell 2016-11-28 13:53:40 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.
Comment 12 Florian Weimer 2017-07-28 11:18:38 UTC 
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.
Note You need to log in before you can comment on or make changes to this bug.