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

[Michael Biebl]

Control: severity -1 normal

Hi Simon

Am 12.01.2017 um 20:10 schrieb 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.

Nod

> 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.

Thanks for implementing that. Given this change in libnss-mdns, I'm
going to downgrade the severity to non-RC.


>> 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.

There are a lot of packages which don't make sense to have installed
alongside systemd. Adding Conflicts to all of them is not a path I want
to go down

> 
>>> 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?

We'll have to look into this. This change was made by Felipe in
7da95fd9f9a2330ffd3132c6673b25f929a78f09 for #789006. Maybe it was
unintentional for mymachines (the original bug report was for myhostname)

Felipe, can you chime in here?


>>> 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.


Thanks for the detailed analysis!

Regards,
Michael


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-systemd-maintainers/attachments/20170113/d43d03df/attachment-0001.sig>