Bug#813471: network access to the loopback device should be allowed
On Thu, 10 May 2018 at 17:51:19 +0100, Ian Jackson wrote:
> Simon McVittie writes ("Bug#813471: network access to the loopback device should be allowed"):
> > Is it legitimate for a package
> > to resolve the reserved name "localhost" during build, and assume that
> > it will get 127.0.0.1 and/or ::1 back?
>
> Yes, assuming that it uses gethostbyname() from the libc.
When you say gethostbyname() I hope you're using that as shorthand
for anything that goes through the libc nsswitch mechanism, like
gethostbyname(), getaddrinfo(), `getent hosts` and so on? (gethostbyname()
is deprecated in favour of getaddrinfo(), because it isn't thread-safe
and can't return a mixture of IPv4 and IPv6 addresses.)
> > - yes, but only if it Build-Depends on libnss-myhostname and/or netbase
>
> I don't know what these things are but I think an system being used
> for builds ought to contain an /etc/hosts giving an IP address for
> `localhost' and enough libc to read it via gethostbyname().
libnss-myhostname is an nsswitch hosts plugin (a backend for
gethostbyname(), getaddrinfo() and friends) which programmatically
resolves localhost, localhost.localdomain and whatever is returned by
gethostname() to plausible IP[v4 and v6] addresses, even if /etc/hosts
is missing or empty. The idea is that it makes the right thing happen
on unconfigured systems, while gracefully staying out of the way if
overridden by configuration (it is canonically configured as the lowest
priority backend in /etc/nsswitch.conf, whereas /etc/hosts is part of
libnss_files which is highest-priority.)
netbase is the Priority: important package that owns files like
/etc/services, and it creates a minimal /etc/hosts (localhost and related
names) in its postinst. For systems installed with d-i, I think d-i
is also involved in the creation of /etc/hosts (it adds the configured
hostname as in the section of hostname(1) that you cited), but not all
systems were installed with d-i, particularly minimal chroots.
> > Similarly, can it assume it can resolve $(hostname) always, or only if
> > it B-D on libnss-myhostname, or never?
>
> I think `resolve $(hostname)' is a bit ambiguous.
Sorry, what I meant is: take the result of gethostname(), and pass it to
libc resolver calls like gethostbyname() or getaddrinfo().
> > At the moment, schroot/sbuild is very likely to make both localhost and
> > $(hostname) resolvable (/etc/hosts from the host system is copied into
> > the chroot, and that file is not strictly guaranteed to make localhost or
> > $(hostname) resolvable but probably does), but pbuilder with its default
> > USENETWORK=no configuration does not necessarily have a hosts file or a
> > working resolv.conf. dbus currently FTBFS on reproducible-builds (#897662)
> > because one of its automated tests assumes localhost is resolvable.
>
> I think this is a bug in pbuiler.
Correction, schroot/sbuild *might* copy in /etc/hosts, but it might not:
as well as /etc/hosts being a configuration file on the host, the list
of files to copy is configurable in each schroot "profile". By default,
the sbuild profile only copies in /etc/resolv.conf, whereas the buildd
profile additionally copies /etc/hosts and /etc/networks. I think official
Debian buildds use the buildd profile, while developers are encouraged
to use the sbuild profile.
This seems increasingly like a trap, with no particular guarantees
currently given to software running in the chroot...
> > I started to implement a feature in pbuilder to make it create a trivial
> > /etc/hosts that can resolve localhost and friends (the same as is created
> > by netbase.postinst) whenever it locks down resolv.conf, but then realised
> > that netbase isn't Essential, so it isn't completely clear whether the
> > resolvability of localhost is part of the basic "API" of a Debian system.
>
> I think it must be part of the basic API for a build environment. I'm
> a bit surprised that netbase isn't build-essential. Certainly IMO an
> /etc/hosts with the entries you describe above should be implied by
> build-essential, one way or another.
The rest of netbase is fairly niche (I suspect few packages need
/etc/protocols or /etc/rpc, and most of the packages that depend on it
do so because they want /etc/services), but it happens to be one of the
few ways to guarantee that you have some sort of /etc/hosts.
smcv
Reply to: