Package: libc6
Version: 2.29-10
Severity: normal

Summarizing the glibc bits of #948834, which I'm about to close because
newer versions of glib2.0 bypass it:

Steps to reproduce

- Be in an environment with only loopback addresses. Using bubblewrap and
  `bwrap --unshare-net --dev-bind / / ./getaddrinfo` is one way to make
  this happen; building in pbuilder is another.

- Have nsswitch configured in such a way that localhost "should" resolve
  to and/or ::1, for example by installing netbase to get
  the typical /etc/hosts, or by installing libnss-myhostname.

- Have a program that resolves names with AI_ADDRCONFIG, which is
  often considered to be a good idea. For example,
  glib2.0's GResolver or dbus' support for TCP addresses.;bug=948834;filename=getaddrinfo.c;msg=30
  is a convenient way to try this out.

- Attempt to resolve the reserved name "localhost" with the AI_ADDRCONFIG
  flag and the AF_INET or AF_INET6 family. (The family not being AF_UNSPEC
  is significant, due to #854301.)

Expected result

localhost resolves to or to ::1, as appropriate for the family.

Actual result

-2 "Name or service not known"


Packages whose regression tests connect to localhost by name FTBFS when
built in pbuilder (but not sbuild or a typical development environment).
This currently affects glib2.0 2.62.x, but not 2.64.x (#948834) and in
the past it affected dbus (#897662).

Developers who expect resolving localhost to succeed become confused
about the layer in which it fails (e.g. expecting the problem to be with

Workarounds that other packages can use

- Implement
  in higher-level resolver APIs (for example glib2.0 >= 2.63.1, recent
  Firefox and recent Chromium do this)

- Implement a special case where AI_ADDRCONFIG is not used for "localhost"
  (for example Firefox has done this for a long time)

- Use AF_UNSPEC (or hints == NULL), and hope #854301 doesn't ever get fixed

- Don't use AI_ADDRCONFIG (generates unnecessary DNS traffic, and
  potentially causes connection delays depending on application behaviour,
  for single-stack hosts)

- On name resolution failure with AI_ADDRCONFIG, retry without AI_ADDRCONFIG
  before giving up

- Configure a useless non- IP address inside network namespaces
  (perhaps to trick AI_ADDRCONFIG into thinking we have IPv4

- Make tests that require resolving localhost skip themselves if it
  doesn't resolve; or don't run such tests at build-time at all, only in
  (IMO undesirable because it significantly reduces test coverage on
  non-amd64, non-arm64 architectures, where the buildds are our only
  opportunity to check that the built package is functional)

Possible solutions in glibc

- Implement a localhost special-case resembling
  at the getaddrinfo() level, before checking AI_ADDRCONFIG

- Implement a localhost special-case that ignores AI_ADDRCONFIG, but then
  delegates to NSS modules as usual

- Instead of implementing AI_ADDRCONFIG at the getaddrinfo() level, pass
  it down to NSS modules, make the dns module respect it (only send DNS
  A/AAAA requests if we have at least one non-local IPv4/IPv6 address),
  and make non-DNS modules like files and myhostname ignore it

- Reject this as not a glibc bug, and recommend that libraries and
  applications use one of the above workarounds
  (suggestions on which ones are the best workarounds welcome!)

Related glibc bug reports

- points out that
  the getaddrinfo() specification implies that AF_UNSPEC should arguably
  also fail in the same way

- points out that
  AI_ADDRCONFIG is not necessarily great to have as a default, for this

- requests that
  IPv6 link-local addresses should be ignored for the purposes of

- requests that
  foo.localhost (for all values of foo) should always resolve to
  and/or ::1 at the getaddrinfo() level, which would avoid this

References outside Debian


Reply via email to