Bug#846944: Installing libnss-resolve before libnss-mdns breaks mDNS name resolution

[Simon McVittie]

Control: clone 846944 -2
Control: reassign -2 libnss-mdns 0.10-7

On Thu, 08 Dec 2016 at 15:20:34 +0100, Michael Biebl wrote:
> With multiple packages mangling nsswitch.conf, this feels like it's
> becoming very brittle and maybe we need a proper API like pam-auth-update.

That would be nice, but let's not block on that for stretch.

On Thu, 08 Dec 2016 at 15:30:53 +0100, Michael Biebl wrote:
> > So maybe the "obvious" fix is to change libnss-mdns to always insert itself
> > before dns *and* resolve? On the other hand, it's quite ugly that mdns needs to
> > be taught to cope with this new nss module.

Solving this in nss-mdns is pretty easy so I'd be OK with going ahead with
that for stretch (and I'd be prepared to consider it RC). Cloning the
bug accordingly. I've written autopkgtests and they seem to work.

> So, libnss-resolve's behaviour of using [!UNAVAIL=return] would break
> LDAP hosts resolution as well.
[...]
> It seems like [!UNAVAIL=return] is generally not safe to use if you
> don't know which NSS modules might come after yours.

Yes. However, I can't think of any other way to get the desired
behaviour of nss-resolve, which is: if systemd-resolved responds
"that name doesn't exist in DNS", don't ask the dns plugin to look it up
in DNS again.

I think the real issue here is perhaps that we have modules that try to
prioritize themselves lower than "dns", but are not a mere fallback like
libnss-myhostname is.

> > libnss-lwres - NSS-Modul um bind9-lwres als Namensdienst zu nutzen

Installation is not automated, and I don't see why anyone would want to
use this and systemd-resolved on the same system anyway (this one only
does traditional port 53 DNS, so it's a strict subset of systemd-resolved).

Perhaps libnss-resolve should just have a Conflicts on it? Using both
makes no sense.

> > libnss-ldap - NSS-Modul für den Einsatz von LDAP als Namensdienst

Installation is not automated, but the example suggests appending ldap
after dns, so libnss-resolve will indeed break it.

But it's orphaned, has many long-standing bugs that to be honest
should probably be RC, and has enough design issues that libnss-ldapd
was written as a replacement... so perhaps libnss-resolve should just
conflict with it and move on. (Remember, this is the plugin that pulls
libldap, GNUTLS, libsasl and Kerberos into every process that looks up
usernames...)

The example configuration says

  # consult DNS first, we will need it to resolve the LDAP host. (If we
  # can't resolve it, we're in infinite recursion, because libldap calls
  # gethostbyname(). Careful!)
  hosts:		dns ldap

which is just horrible tbh - as a bare minimum it should special-case
its own server name to be skipped! libnss-ldapd fixes that design issue.

> > libnss-ldapd - NSS-Modul für den Einsatz von LDAP als Namensdienst

This goes at the end, so libnss-resolve will break it. But
perhaps it shouldn't - its own documentation says

  # hostname lookups through ldap before dns should work now
  hosts:          files ldap dns

> > libnss-myhostname - nss module providing fallback resolution for the current hostname

This goes at the end of the line as a fallback, but systemd-resolved
has all the functionality of libnss-myhostname, so not running it
is harmless.

> > libnss-docker - nss module for finding Docker containers
> > libnss-gw-name - nss module that names the current gateway’s IP address

These are prioritized slightly lower than 'files', so they come before
both mdns and resolve - conceptually, it's as though you added all
your containers, and your gateway, to /etc/hosts. That's fine.

> > libnss-mymachines - nss module to resolve hostnames for local container instances

This is meant to be after files but before resolve (so the same position
as libnss-docker and libnss-gw-name). Are you deliberately installing it with
a lower priority than upstream's recommendation?

> > libnss-libvirt - nss plugin providing IP add ress resolution for virtual machines

Not set up automatically. I'm not sure where it's meant to go; presumably
the same place as libnss-docker, in which case it's fine?

> > libnss-sss - Nss-Modul für den SSS-Daemon (System Security Services)
> > libnss-cache - NSS module for using nsscache-generated files
> > libnss-extrausers - nss module to have an additional passwd, shadow and group file
> > libnss-mysql-bg - NSS module for using MySQL as a naming service
> > libnss-pgsql2 - NSS module for using PostgreSQL as a naming service
> > libnss-securepass - NSS (Name Service Switch) module for Securepass
> > libnss-db - NSS-Modul für die Verwendung der Berkeley-Datenbank als Namensdienst
> > libnss-rainbow2 - nss library for rainbow
> > libnss-winbind - Samba nameservice integration plugins
> > libnss-systemd - nss module providing dynamic user and group name resolution

These don't seem to do hosts.

> > libnss-wrapper - NSS wrapper library

False positive: it's an LD_PRELOAD hack to manipulate the nsswitch, not
a normal nsswitch plugin.

Regards,
    S