[snap] Snapped apps do not work with .local mdns/avahi name resolution

I'm testing on my laptop with the avahi daemon running, and `python3 -m http.server 8000`, and the chromium snap correctly resolves http://bribon.local:8000, so it seems to be working.

I wonder whether this test is not meaningful?

well, try something thats not on localhost, i know that i cant resolve anything in my LAN that uses mdns (note that this will also affect printing i guess)

trying your test on any of my machines does not work here btw (so i assume it has nothing to do with running the server locally)

after a comment from jamesh in the forum discussion i found that installing nscd from universe works around the issue, but this does not change the fact that it is a regression of an ubuntu default feature, so there still needs to be some solution (snapd dependency on nscd and moving nscd back into main, fixing nssswitch.conf inside the core/core18 snap or some other new solution)

I just checked and neither nscd nor unscd is installed on my laptop. I tried again the test in comment #1 for good measure, and it's still working (rebooted several times and refreshed the chromium snap in the meantime).

So the chromium snap correctly resolves .local addresses only for the same host, it doesn't work for a different physical host on the local network. As suggested by jamesh and ogra, installing nscd and restarting chromium makes resolution of .local addresses work.

I added a snapd bug task per https://forum.snapcraft.io/t/chromium-does-not-work-with-local-mdns-avahi-name-resolution/12483/7.

I just attempted to reproduce this issue with:

- snapd 2.24~pre2 on Ubuntu 19.04
- chromium snap revision 861

I installed apache2 locally via apt and opened the link "fyke.local" in both Firefox and Chromium. Note that Firefox accepted just fyke.local and did the right thing while Chromium would search google unless I spelled the link as "http://fyke.local".

Perhaps this issue has been fixed since, marking as incomplete.

@zyga: see comment #6, resolving .local addresses works on the same host, but it doesn't for a different physical host on the local network.

I see, it needs to be debugged further to determine what the problem is. Unfortunately due to the design of snapd's handling of /etc (shared with the host, with small exceptions), it is possible that the solution is complex and could take some time to implement.

I can confirm this. I am also using Chromium and cannot access the web admin interface of my printer, via

http://HP18602408C229.local/

In Firefox this works.

Same for the snap I am working on, to provide CUPS and cups-browsed in a snap:

https://github.com/OpenPrinting/printing-stack-snap/

cups-browsed is also not able to resolve ".local" host names if the host is in the local network but not the local machine, exactly as Chromium.

So it seems to be a problem for snapped applications in general.

I have to install nscd on the host machine and then restart snapd and my snap:

sudo systemctl restart snapd
sudo snap restart printing-stack-snap

and after that cups-browsed succeeds to resolve .local host names.

Now with nscd running and snapd restarted I have also cloded and re-opened the Chromium browser and I can access my printer's web interface now.

Adding snap-core18 and snap-core20 tasks as it is a problem of core18 and core20 missing support for looking up host names via mDNS/DNS-SD. The problem occurs also in other Snaps not only in the Chromium Browser Snap. Therefore the fix for this bug is essentially important and urgently needed.

Note that installing nscd is only a workaround, which can cause security problems (aacording to Jamie Strandboge) when seeding it and also it would only help Ubuntu users.

Especially also the CUPS Snap (https://github.com/OpenPrinting/cups-snap) and Printer Application Snaps (the way to snap printer and scanner drivers, required for the CUPS Snap, currently, we have the PostScript Printer Application, https://github.com/OpenPrinting/ps-printer-app) are affected as they internally use mDNS .local addresses to access network devices. As we want to switch over printing in Ubuntu to the CUPS Snap and also want to give manufacturers a way to publish distribution-independent snapped printer/scanner drivers this problem needs to get urgently fixed.

A suggested fix can be found in this thread:

https://forum.snapcraft.io/t/no-mdns-support-in-snaps-should-core-have-a-modified-nsswitch-conf/

The /etc/nsswitch.conf file needs a simple change, replacing the line

hosts: files dns

by

hosts: files mdns4_minimal [NOTFOUND=return] dns

and the libnss-mdns package (provides libnss_mdns*.so*) needs to get installed into the coreXX images.

Applied a Snap-side workaround to my Snaps which implements the fix presented in the snapcraft.io thread mentioned in my previous post:

CUPS Snap:

https://github.com/OpenPrinting/cups-snap/commit/f241f3f02

PostScript Printer Application:

https://github.com/OpenPrinting/ps-printer-app/commit/1f6ca389

Note that doing this on any Snap which needs it in the future is awkward, so we really need to fix core18 and core20.

Just repeating what I said on the forum, I believe this could be implemented through updates to the base snaps with no changes to snapd or any application snaps.

The mdns4_minimal NSS plugin is an 18K binary (which compresses to about 6KB) that delegates its lookups to avahi-daemon using a single purpose lookups-only unix socket protocol (i.e. no D-Bus access). The AppArmor <abstractions/nameservice> policy fragment grants access to this socket, so any snap plugging "network" already has permission to communicate.

If the plugin cannot connect to Avahi, it should error out very quickly.

Updating the base snaps to include the NSS plugin and reference it in their nsswitch.conf file would likely be all that is needed. It should work equally well for applications on classic distros and those on Ubuntu Core with the avahi snap installed.