[Bug libc/12398] New: loopback addresses shouldn't be disregarded by getaddrinfo()+AI_ADDRCONFIG when looking up "localhost"

[Bug libc/12398] New: loopback addresses shouldn't be disregarded by getaddrinfo()+AI_ADDRCONFIG when looking up "localhost"

[tore at fud dot no]

http://sourceware.org/bugzilla/show_bug.cgi?id=12398

           Summary: loopback addresses shouldn't be disregarded by
                    getaddrinfo()+AI_ADDRCONFIG when looking up
                    "localhost"
           Product: glibc
           Version: 2.13
            Status: NEW
          Severity: normal
          Priority: P2
         Component: libc
        AssignedTo: drepper.fsp@gmail.com
        ReportedBy: tore@fud.no


getaddrinfo() will disregard the loopback addresses ::1 and 127.0.0.1 when
attempting to figure out which address families are present on the host, when
being called with the AI_ADDRCONFIG flag.

This makes a lot of sense when looking up an external hostname.  However, it
makes very little sense when connecting to the hostname "localhost".  I've
learned that the browser vendors will avoid using AI_ADDRCONFIG or do it while
using workarounds for the localhost case, see for instance:

https://bugzilla.mozilla.org/show_bug.cgi?id=614526

Without such a workaround, connecting to a IPv4-only service listening on
127.0.0.1 using the hostname "localhost" will fail unless the machine also has
external IPv4 connectivity.  Which is not what a user would expect, since the
(lack of) external connectivity is irrelevant to the accessibility to the
loopback interface.

Therefore, when looking up "localhost", the loopback addresses ::1 and
127.0.0.1 should not be ignored by getaddrinfo() when using AI_ADDRCONFIG

Tore

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug libc/12398] loopback addresses shouldn't be disregarded by getaddrinfo()+AI_ADDRCONFIG when looking up "localhost"

[nick.jones@network-box.com]

http://sourceware.org/bugzilla/show_bug.cgi?id=12398

nick.jones@network-box.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |nick.jones@network-box.com

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug network/12398] loopback addresses shouldn't be disregarded by getaddrinfo()+AI_ADDRCONFIG when looking up "localhost"

[jsm28 at gcc dot gnu.org]

http://sourceware.org/bugzilla/show_bug.cgi?id=12398

Joseph Myers <jsm28 at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|libc                        |network

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug network/12398] loopback addresses shouldn't be disregarded by getaddrinfo()+AI_ADDRCONFIG when looking up "localhost"

[psimerda at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=12398

Pavel Šimerda <psimerda at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |psimerda at redhat dot com

--- Comment #1 from Pavel Šimerda <psimerda at redhat dot com> 2012-07-27 14:11:30 UTC ---
The same applies to *all* link-local IPv6 addresses as well as link-local IPv4
addresses.

The same applies for all alternative names for localhost:

For example on Fedora:

127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6

People even use FQDNs for their localhost address to test their stuff without
network connection.

See also comments in bug 12377.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug network/12398] loopback addresses shouldn't be disregarded by getaddrinfo()+AI_ADDRCONFIG when looking up "localhost"

[psimerda at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=12398

--- Comment #2 from Pavel Šimerda <psimerda at redhat dot com> 2012-07-28 10:12:58 UTC ---
Currently with glibc-2.15-51.fc17.x86_64 I can reproduce it with:

  hints.ai_family = AF_INET6;
  hints.ai_flags = AI_ADDRCONFIG; // and optional AI_V4MAPPED

I can no longer reproduce with SSH (possibly because of some updates
that affect SSH's networking, i don't know).

My feeling is that we should *never* discard literal IP adresses
based on AI_ADDRCONFIG. At least not unless we check against
*family* together with *scope* but even then it's very doubtful
to go directly against user's input.

As for names like 'localhost', 'localhost4' and various names you can
use for node-local and link-local addresses, I'm strictly against trying
to enumerate them as you cannot guess all possible names. Would
you for example check the suffix ".local" and treat the result as a
link-local FQDN? But it may be a global address also.

I actually don't believe in any checks that work with the name and
not the address. When you have the address, you can check it against
several rules to guess (and usually know) the scope.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug network/12398] loopback addresses shouldn't be disregarded by getaddrinfo()+AI_ADDRCONFIG when looking up "localhost"

[orion at cora dot nwra.com]

http://sourceware.org/bugzilla/show_bug.cgi?id=12398

Orion Poplawski <orion at cora dot nwra.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |orion at cora dot nwra.com

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug network/12398] loopback addresses shouldn't be disregarded by getaddrinfo()+AI_ADDRCONFIG when looking up "localhost"

[psimerda at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=12398

--- Comment #3 from Pavel Šimerda <psimerda at redhat dot com> 2012-09-22 15:42:40 UTC ---
Created attachment 6647
  --> http://sourceware.org/bugzilla/attachment.cgi?id=6647
a temporary fix to ignore the whole AI_ADDRCONFIG thing

Until this issue is resolved, I'm building GLIBC with this patch to avoid
problems with node-local and link-local networking.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug network/12398] AI_ADDRCONFIG breaks getaddrinfo() calls for loopback names and addresses

[psimerda at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=12398

Pavel Šimerda <psimerda at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|loopback addresses          |AI_ADDRCONFIG breaks
                   |shouldn't be disregarded by |getaddrinfo() calls for
                   |getaddrinfo()+AI_ADDRCONFIG |loopback names and
                   |when looking up "localhost" |addresses

--- Comment #4 from Pavel Šimerda <psimerda at redhat dot com> 2012-11-20 23:13:20 UTC ---
By the way, I just learned that the current behavior is not mandated by POSIX.
Thanks to Jeff Law for valuable information he provided:

http://pubs.opengroup.org/onlinepubs/9699919799/

If the AI_ADDRCONFIG flag is specified, IPv4 addresses shall be returned only
if an IPv4 address is configured on the local system, [IP6] [Option Start]  and
IPv6 addresses shall be returned only if an IPv6 address is configured on the
local system. [Option End]

Jeff: It may also be the case that we need to involve the "Austin Group" if we
need further clarification of the standard (link-local handling comes to mind).

My summary is:

Filtering of non-DNS addresses in getaddrinfo() has no real use
and it only causes problems. There's no reason to filter over the
mere existence of addresses. Filtering over global address existence
may only be desirable for global address resolution, which is DNS. But
that should be done by the DNS resolver that only asks for addresses
that make sense and only accepts addresses that it asks for.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug network/12398] AI_ADDRCONFIG breaks getaddrinfo() calls for loopback names and addresses

[psimerda at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=12398

--- Comment #5 from Pavel Šimerda <psimerda at redhat dot com> 2012-11-20 23:32:57 UTC ---
Changed the comment. Currently, I'm using the following patch to fix my
node-local IPv4/IPv6 networking (link-local networking is currently not
broken in Fedora since they removed the patch to also disregard link-local
addresses). I'm proposing this patch as a temporary solution until this
s fixed properly with the following notes:

* It breaks POSIX1-2008 (which requires checking for any IPv4/IPv6 address)
* It breaks informational RFC 3493 (which requires the same but disregards the
loopback interface)
* It ignores the older informational RFC 2553 (which requires the same as RFC
3494 but only for DNS lookups)

The POSIX1-2008, RFC 3493 and obsolete RFC 2553 are all effectively useless
but the obsolete one is closest to the truth. Whether a global IPv4 address,
a global IPv4 route, or a global IPv4 default gateway is the right sign of
global connectivity, is up to discussion.

I also changed the description of the bug to reflect the actual problem,
not one possible (maybe wrong, but at least POSIX-compliant) solution of that
problem.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug network/12398] AI_ADDRCONFIG breaks getaddrinfo() calls for loopback names and addresses

[psimerda at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=12398

--- Comment #6 from Pavel Šimerda <psimerda at redhat dot com> 2012-11-20 23:36:30 UTC ---
Upstream bug report:

https://bugzilla.redhat.com/show_bug.cgi?id=721350

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug network/12398] AI_ADDRCONFIG breaks getaddrinfo() calls for loopback names and addresses

[psimerda at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=12398

--- Comment #7 from Pavel Šimerda <psimerda at redhat dot com> 2012-11-20 23:38:58 UTC ---
Another upstream bug report:

https://bugzilla.redhat.com/show_bug.cgi?id=808147

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug network/12398] AI_ADDRCONFIG breaks getaddrinfo() calls for loopback names and addresses

[gaofeng at cn dot fujitsu.com]

http://sourceware.org/bugzilla/show_bug.cgi?id=12398

Gao feng <gaofeng at cn dot fujitsu.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |gaofeng at cn dot
                   |                            |fujitsu.com

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug network/12398] AI_ADDRCONFIG breaks getaddrinfo() calls for loopback names and addresses

[tore at fud dot no]

http://sourceware.org/bugzilla/show_bug.cgi?id=12398

--- Comment #8 from Tore Anderson <tore at fud dot no> 2012-12-16 13:47:03 UTC ---
Created attachment 6781
  --> http://sourceware.org/bugzilla/attachment.cgi?id=6781
Move AI_ADDRCONFIG into gaih_inet()

Attached patch moves AI_ADDCONFIG processing into gaih_inet(). This improves
things by making it not apply to literal IP addresses. However, AI_ADDCONFIG
will still be able to suppress results from both address families for things
coming out of /etc/hosts like for example "localhost". In order to prevent that
I think we'd need to move AI_ADDRCONFIG into _nss_dns_gethostbyname*(), which
is beyond my programmings skills to implement I'm afraid.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug network/12398] getaddrinfo("127.0.0.1") and/or getaddrinfo("::1) may fail with AI_ADDRCONFIG

[psimerda at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=12398

Pavel Šimerda <psimerda at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|AI_ADDRCONFIG breaks        |getaddrinfo("127.0.0.1")
                   |getaddrinfo() calls for     |and/or getaddrinfo("::1)
                   |loopback names and          |may fail with AI_ADDRCONFIG
                   |addresses                   |

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug network/12398] getaddrinfo("127.0.0.1") and/or getaddrinfo("::1) may fail with AI_ADDRCONFIG

[psimerda at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=12398

--- Comment #9 from Pavel Šimerda <psimerda at redhat dot com> 2012-12-17 17:30:11 UTC ---
(In reply to comment #8)
> Created attachment 6781 [details]
> Move AI_ADDRCONFIG into gaih_inet()
> 
> Attached patch moves AI_ADDCONFIG processing into gaih_inet(). This improves
> things by making it not apply to literal IP addresses. However, AI_ADDCONFIG
> will still be able to suppress results from both address families for things
> coming out of /etc/hosts like for example "localhost". In order to prevent that
> I think we'd need to move AI_ADDRCONFIG into _nss_dns_gethostbyname*(), which
> is beyond my programmings skills to implement I'm afraid.

I tested the patch and confirm that I don't see any regressions.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug network/12398] getaddrinfo("127.0.0.1") and/or getaddrinfo("::1) may fail with AI_ADDRCONFIG

[psimerda at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=12398

Pavel Šimerda <psimerda at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|drepper.fsp at gmail dot    |unassigned at sourceware
                   |com                         |dot org

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug network/12398] getaddrinfo("127.0.0.1") and/or getaddrinfo("::1) may fail with AI_ADDRCONFIG

[phattanon at nettree dot co.th]

http://sourceware.org/bugzilla/show_bug.cgi?id=12398

Phattanon Duangdara <phattanon at nettree dot co.th> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |phattanon at nettree dot
                   |                            |co.th

--- Comment #10 from Phattanon Duangdara <phattanon at nettree dot co.th> 2013-02-09 17:53:44 UTC ---
Can someone point out that this should also fixed this bug ?

http://sourceware.org/bugzilla/show_bug.cgi?id=14212

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug network/12398] getaddrinfo("127.0.0.1") and/or getaddrinfo("::1) may fail with AI_ADDRCONFIG

[psimerda at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=12398

--- Comment #11 from Pavel Šimerda <psimerda at redhat dot com> 2013-02-09 21:10:59 UTC ---
(In reply to comment #10)
> Can someone point out that this should also fixed this bug ?
> 
> http://sourceware.org/bugzilla/show_bug.cgi?id=14212

This bug report is *not* related to the hosts nss plugin and is rather easy to
fix.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug network/12398] getaddrinfo("127.0.0.1") and/or getaddrinfo("::1) may fail with AI_ADDRCONFIG

[psimerda at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=12398

Pavel Šimerda <psimerda at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at sourceware    |psimerda at redhat dot com
                   |dot org                     |

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug network/12398] getaddrinfo("127.0.0.1") and/or getaddrinfo("::1) may fail with AI_ADDRCONFIG

[neleai at seznam dot cz]

https://sourceware.org/bugzilla/show_bug.cgi?id=12398

Ondrej Bilka <neleai at seznam dot cz> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |neleai at seznam dot cz

--- Comment #12 from Ondrej Bilka <neleai at seznam dot cz> ---
Did you send this patch to libc-alpha?

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug network/12398] getaddrinfo("127.0.0.1") and/or getaddrinfo("::1) may fail with AI_ADDRCONFIG

[psimerda at redhat dot com]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="UTF-8", Size: 3874 bytes --]

https://sourceware.org/bugzilla/show_bug.cgi?id=12398

--- Comment #13 from Pavel Å imerda <psimerda at redhat dot com> ---
(In reply to Ondrej Bilka from comment #12)
> Did you send this patch to libc-alpha?

Nope. Maybe we could discuss the libc development process some time in Prague
or at LinuxAlt Brno? I'm not very familiar with it.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
>From glibc-bugs-return-19922-listarch-glibc-bugs=sources.redhat.com@sourceware.org Tue Oct 22 12:07:54 2013
Return-Path: <glibc-bugs-return-19922-listarch-glibc-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-glibc-bugs@sources.redhat.com
Received: (qmail 32178 invoked by alias); 22 Oct 2013 12:07:53 -0000
Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <glibc-bugs.sourceware.org>
List-Subscribe: <mailto:glibc-bugs-subscribe@sourceware.org>
List-Post: <mailto:glibc-bugs@sourceware.org>
List-Help: <mailto:glibc-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: glibc-bugs-owner@sourceware.org
Delivered-To: mailing list glibc-bugs@sourceware.org
Received: (qmail 32123 invoked by uid 48); 22 Oct 2013 12:07:49 -0000
From: "libnoon at gmail dot com" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug manual/16073] New: Improve the manual on symbolic links
Date: Tue, 22 Oct 2013 12:07:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: glibc
X-Bugzilla-Component: manual
X-Bugzilla-Version: unspecified
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: libnoon at gmail dot com
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at sourceware dot org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter cc attachments.created
Message-ID: <bug-16073-131@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2013-10/txt/msg00281.txt.bz2
Content-length: 1499

https://sourceware.org/bugzilla/show_bug.cgi?id\x16073

            Bug ID: 16073
           Summary: Improve the manual on symbolic links
           Product: glibc
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: manual
          Assignee: unassigned at sourceware dot org
          Reporter: libnoon at gmail dot com
                CC: mtk.manpages at gmail dot com, roland at gnu dot org

Created attachment 7246
  --> https://sourceware.org/bugzilla/attachment.cgi?idr46&actioníit
The proposed patch.

Hello libc developers,

This is the bugzilla entry for a discussion on libc-help that started on
12OCT2013.

Currently the manual documents the symlink() function as this:

Function: int symlink (const char *oldname, const char *newname)
The symlink function makes a symbolic link to oldname named newname. [...]

I find it impractical because, as I can never remember if the symlink
is the first or second argument, I have to think about OLDNAME and
NEWNAME to realize that NEWNAME is actually the symlink, while OLDNAME
the contents of the symlink.

It has been a long time since I thought it would be clearer if the
parameters were simply named TARGET and LINKNAME.

I have made this change in the attached patch, along with a few
additions/corrections on filesys.texi.

Could you please review it?

Thanks!

Best regards
Fabrice

--
You are receiving this mail because:
You are on the CC list for the bug.

[Bug network/12398] getaddrinfo("127.0.0.1") and/or getaddrinfo("::1) may fail with AI_ADDRCONFIG

[jackie.rosen at hushmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=12398

Jackie Rosen <jackie.rosen at hushmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jackie.rosen at hushmail dot com

--- Comment #14 from Jackie Rosen <jackie.rosen at hushmail dot com> ---
*** Bug 260998 has been marked as a duplicate of this bug. ***
Seen from the domain http://volichat.com
Page where seen: http://volichat.com/adult-chat-rooms
Marked for reference. Resolved as fixed @bugzilla.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug network/12398] getaddrinfo("127.0.0.1") and/or getaddrinfo("::1) may fail with AI_ADDRCONFIG

[schwab at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=12398

Andreas Schwab <schwab at sourceware dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|jackie.rosen at hushmail dot com   |

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug network/12398] getaddrinfo("127.0.0.1") and/or getaddrinfo("::1) may fail with AI_ADDRCONFIG

[fweimer at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=12398

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
              Flags|                            |security-

-- 
You are receiving this mail because:
You are on the CC list for the bug.