Add mDNS local device discovery portal

[hadess]

To implement .local device discovery (as opposed to service discovery), it would be useful to have a portal that does that lookup, using either Avahi or systemd-resolved depending on the system configuration. This would also allow for permissions to be requested when the application starts using this functionality.

Prior art

iOS

• Twitter would like to find and connect to devices on your local network
• Support local network privacy in your app

[TingPing]

Prior art

Just to state the obvious: There is a difference from iOS since flatpak does nothing to prevent network access.

[hadess]

Just to state the obvious: There is a difference from iOS since flatpak does nothing to prevent network access.

It's a useful API to have whether or not particular types of network access are prevented, or rather until they are.

[nanonyme]

Does this go through glibc resolver? If yes, then there could be a plugin configured through nsswitch.conf that would communicate to a portal in host. (fallbacking regular DNS) This would probably not require changes in flatpak?

[hadess]

Does this go through glibc resolver? If yes, then there could be a plugin configured through nsswitch.conf that would communicate to a portal in host. (fallbacking regular DNS) This would probably not require changes in flatpak?

I don't think there's currently any way to extension points for NSS plugins, is there? If that were the case, it might be a useful stop-gap until we have a portal for mDNS support, not a complete replacement for it.

[nanonyme]

systemd-resolved now has access to host varlink out of the box when --share=network is given through flatpak/flatpak@e5da98f; freedesktop-sdk 21.08 will contain required NSS plugins and configurations.

[hadess]

systemd-resolved now has access to host varlink out of the box when --share=network is given through flatpak/flatpak@e5da98f; freedesktop-sdk 21.08 will contain required NSS plugins and configurations.

As I mentioned in systemd/systemd#18860 (comment) this unfortunately gives access to more information about the local network than what was previously allowed.

[Mikenux]

What is the scope of this portal?

• Allow an app to discover local devices to present them in its own UI?
• Allow an app to connect to a chosen local device in a portal UI?
• Is it all local devices and/or specific devices (e.g. only those with the same multiplayer game)?

[qwertychouskie]

Has there been any progress on this? This is a big issue for anyone who uses a Flatpak web browser and tries to connect to something on their local network, but just gets a "The connection has timed out" error for mysterious reasons. I suspect the only reason there aren't many more people on this thread is the fact that it is not at all obvious that Flatpak is the reason why they can't connect.

If there's anything I can do to help out. please let me know :)

[swick]

AFAIK there has been no work on this. If you want to pick this up feel free to do so and if you have questions there is the #xdg-desktop-portals:matrix.org channel.

[hfiguiere]

Linked freedesktop-sdk issue, FYI
https://gitlab.com/freedesktop-sdk/freedesktop-sdk/-/issues/1013

[freundTech]

I've read through all the discussions on this and would suggest the following way forward. I don't know if I have enough free time to implement all of this, but I might start the work.

• Define the portal API
• Write the portal implementation (asking for permission and calling to avahi or systemd-resolved, depending on the system)
• Write an NSS plugin calling the API via dbus
• Get the NSS plugin into the freedesktop runtime.

I don't think we need a backend interface and implementation. The Access backend implementation should be enough.

[nanonyme]

So is the intent that unless hostname ends in .local, the NSS plugin will immediately fail so glibc will switch to next resolver?

[freundTech]

On a basic level yes. That's also what avahi's libnss_mdns seems to be doing (though their logic is a bit more complex. They read /etc/mdns.allow to check which domains should be resolved using mdns)

[nanonyme]

Wait, does this mean if flatpak was changed to mount mdns.allow from host and we provided libnss_mdns in sandbox (and relevant nsswitch.conf configuration), it would already now work if user allows mdns dbus socket?

[nanonyme]

Just wondering if this portal design is overkill

[Mikenux]

Re-reading, you seem to want name resolution and not really device discovery. What is being targeted really needs to be clarified.

[freundTech]

@nanonyme The problem that came up in earlier approaches is that there are multiple mDNS implementations that distros might use. Some distros use Avahi while others use systemd-resolved.
To support this in general you would have to mount the systemd-resolved socket into the sandbox, allow access to the avahi dbus socket to the sandbox and set /etc/nsswitch.conf to use the option the host system uses.

That's where the idea of using a portal came in. The portal would offer one standardized way for sandboxed applications to resolve mDNS names and take care of all the implementation details.

[nanonyme]

Does systemd use mdns.allow config though? Maybe we could just use both nss to plugins.

[Mikenux]

@freundTech:

The Access backend implementation should be enough.

If you mean requesting access to all local devices, I would say no. It is generally better to access individual objects (here devices) rather than all objects when several can be distinguished. We can then wonder if it makes sense to access individual objects rather than all of them.

In this case, giving permission to individual objects rather than all allows communication only with the relevant devices. This also prevents the app from knowing all the devices we own (this provides a bit of privacy).

Additionally, if this applies, it would probably be useful to distinguish between listing all available devices and only listing devices using a specific protocol to communicate (e.g. games). Note that here I only followed the links given in the first post.

Finally, if there is a reason to let an app always discover and access any local (network) device rather than the app getting a list of all available devices, then it is best to know what the case is and if we can have both (select devices from a list and always discover and access those).

[freundTech]

@Mikenux I think what you're describing goes a lot further than what mDNS is and can do.

First of all we can't prevent an app from accessing local devices. mDNS is only about finding local devices. If you already know the IP (or guess or brute-force it) you can still talk to it. Also because there are no networking restrictions an app could probably still manuall implement mDNS to discover devices.
This is about making mDNS work for apps that don't know about mDNS and just use standard libc functions to connect to a .local domain (like when typing a .local domain into a flatpaked web-browser).

Second mDNS doesn't have a way to list all local devices, so we can't show a list to users and have them choose a device. mDNS also doesn't have a way to discover what services a device offers (that's where DNS-SD would come in, which can but doesn't have to be used on top of mDNS. But that's a completely different topic).

We could have fine grained permissions on a per-domain level ("Allow $app to access foo.local?"). I personally don't think that this is worth the effort and would prefer a general permission ("Allow $app to discover local devices?"). Asking too many questions might get annoying for users (though I'm willing to have my mind changed on this).
Nevertheless, both of those cases can be implemented using the Access backend implementation, as they are just yes/no questions.

[Mikenux]

@swick: Overall, I'm talking about having what is needed to distinguish Internet access from LAN access (which includes mDNS local device discovery) for the network "portal".

@nanonyme: If kernel support is needed, then this should be worked on. However, this will require a new kernel, which is inconvenient. Just that in the current state it would be better to just be able to enable the feature without requesting access. Indeed, from my user perspective, it doesn't really make sense to request access to local devices if we already have access to the local network (regardless of the underlying protocols).

Also, can anyone explain what "bikeshedding" is? I still have trouble understanding this word in context. Thanks!

[nanonyme]

@Mikenux there has been talk for last few years of need for unprivileged network namespaces. I'm not holding my breath anything will materialize this decade.

[Erick555]

unpriv network namespaces are possible right now.

[nanonyme]

Really? Then under that kind of environment for sure this granular DNS limiting might make sense.

[Mikenux]

... I forgot this was available (even saw them mentioned in network issues here and in flatpak). For the network portal: #1166.

However, first knowing the status on this point is necessary. If nothing can happen within a given time frame, then other solutions can be considered.

[Erick555]

Since flatpak is in maintenance mode landing new features is a rather rare thing.

[Mikenux]

@Erick555: What does this mean regarding this issue?

[Erick555]

It means introducing network namespaces support and more sophisticated network access than on/off may be unlikely in the foreseeable future.

[freundTech]

I did some prototyping and apparently the Access backend implementation (at least on gnome) only allows the currently focused application to show a permission dialog. This in my opinion makes it impractical to ask for permission for every mDNS name.

As I would expect mDNS lookups to sometimes happen in the background this makes me prefer only showing a dialog once to allow mDNS lookups for all domains even more.

[nanonyme]

Yeah, it would be nice if app could declare in its manifest that it really needs this access to bypass any prompt.

[stephen304]

Also agree with the "grant once for everything" option, I don't see firefox mentioned here yet so just putting it here, I want mDNS resolution in flatpak firefox so I can access things like synology.local and octoprint.local, and I think most people wouldn't want to have to grant access every time they type in a new .local address into the address bar vs just granting all mDNS access to firefox once.

[Mikenux]

@nanonyme: No way to bypass a prompt, at least this is not something an app can decide. For this, there are static permissions. With portals, a permission request is presented to the user.

As I would expect mDNS lookups to sometimes happen in the background

Allowing mDNS lookups is ok, but only if the app can't see the devices (and therefore tries to access them). In my opinion, the most reasonable route to take is to have a dialog to display discovered "devices" and to prompt when a .local address is entered.

[Mikenux]

With the little information I have, maybe we have the following choices:

1. Have mDNS being external (i.e. system-side) and use gvfs mounts to have per device access. This comes from A portal for network (and other) gvfs mounts #102. To note: that's gvfs but I believe KDE don't use that. If so and a portal is using gvfs specific interaction, it will not be intended for general consumption (except if others adopt gvfs).
2. Have the general access as you @freundTech suggested. First, it's important to remember that we're talking about accessing devices, not just discovering them (wording must reflect that). Second, this can be the choice if the first one is failing on something for now or the future, e.g. incompatibility using some other protocol to communicate between devices, like games, not for general consumption...

[Mikenux]

Here are 3 cases identified here:

1. Device-to-device communication (the example of games). This is probably the object of another issue, as I suppose this one is more focused on the other two.
2. Access to system-side discovered local file shares.
3. Connecting to local file shares.

The problem is file access. Concerning this access, offering the user to precisely select the files to give to an application is important to limit access. This is a bit of a problem for applications whose main functionality is to connect to local file shares to browse them.

So, what kind of cases are you targeting?

[ZanderBrown]

Somewhat impressively not one of those is what this issue is actually about?

[Mikenux]

It’s about discovering the devices. However, is there a case where it's about discovering devices without accessing them?

[Mikenux]

Also look at the links provided in the first post and comments, which may explain why a portal never materialized.

[teohhanhui]

@ZanderBrown @/Mikenux has been known to do that around this issue tracker for years. So this is nothing new.

[Mikenux]

And that's why I can say that the reasoning for creating a portal is not "I want this feature, so I'm creating a portal asking to enable it because I'm asking for permission."

For this issue, given...

• device diversity: file shares, device-to-device communication, web interfaces (which also includes web interfaces for file shares);
• lack of protection: no separation between LAN and internet access, no way to launch an application with independent settings (Support independent instances (profiles) for a single app flatpak#1170; tagged for STF), or the fact that we also give the username and password to the application;

...I don't think there's much chance of getting a general permission accepted.

A slightly more acceptable solution if we forget the username and password part (which does not mean it will be accepted) is to have permission per device/domain. Note that currently, the user can use the IP address of these devices or web interfaces (which can also be an argument for rejection).

[ninja-]

I don't think this should be a portal, even if the portal prototype is finished it would have a very slow adoption.
Just integrate it into glibc resolver from inside freedesktop runtime, possibly taking into account dbus permissions of org.freedesktop.Avahi

[nanonyme]

Runtime is not a security boundary. If it was in glibc resolver, then any permissions belong to portal or D-Bus proxy.

[ninja-]

it's fine to use org.freedesktop.Avahi access as a security boundary and let runtime use it when available

[nanonyme]

Actually no. Let's not. We already noticed with systemd-resolved that having glibc resolver connect to D-Bus is a very bad idea. It will hang until timeout if host is missing D-Bus host.

[Mikenux]

What really seems necessary is to clearly state what is wanted, because, in my opinion, there is clearly confusion about this on various issues.

For me, what is wanted here - at least by the people concerned with this issue - is a name resolver: the app sends a local name and the "system" returns the IP. Make sure that this is how maintainers or others interpret your vision of "device discovery" when you discuss it with them.