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. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to chromium-browser in Ubuntu. https://bugs.launchpad.net/bugs/1838038 Title: [snap] Snapped apps do not work with .local mdns/avahi name resolution Status in snap-core18: New Status in snap-core20: New Status in snapd: Triaged Status in chromium-browser package in Ubuntu: Confirmed Bug description: (initially reported at https://forum.snapcraft.io/t/chromium-does-not- work-with-local-mdns-avahi-name-resolution/12483) The current chromium snap does not allow to open any .local urls. This is most likely caused by https://forum.snapcraft.io/t/no-mdns- support-in-snaps-should-core-have-a-modified-nsswitch-conf/7603. With the removal of the chromium deb and the switch to a snap-only deployment for this browser this is a pretty solid regression that should be addressed… To manage notifications about this bug go to: https://bugs.launchpad.net/snap-core18/+bug/1838038/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : [email protected] Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
