Moonlight - mDNS broken with AppArmor denials for AF_NETLINK since update to Qt 5.12

The moonlight snap recently moved from Qt 5.9 to Qt 5.12 on the edge channel, and this apparently broke mDNS discovery. The app prints these logs every 10s, which is interval that QMdnsEngine sends mDNS queries:

Qt Critical: Could not create AF_NETLINK socket (Permission denied)

And dmesg is filled with these:

audit: type=1400 audit(1589678896.333:58283): apparmor="DENIED" operation="create" profile="snap.moonlight.moonlight" pid=2984522 comm="moonlight" family="netlink" sock_type="dgram" protocol=0 requested_mask="create" denied_mask="create"
audit: type=1400 audit(1589678896.345:58284): apparmor="DENIED" operation="create" profile="snap.moonlight.moonlight" pid=2984522 comm=517420626561726572207468726561 family="netlink" sock_type="dgram" protocol=0 requested_mask="create" denied_mask="create"

Either rebuilding with Qt 5.9, installing with --devmode, or manually connecting any of network-observe or netlink-connector fix both the mDNS discovery and the apparmor denials (while avahi-observe makes no difference).

Any ideas? Thanks!

A very similar issue:

The snap bug report, for reference:

@jdstrand, I think you might be able to help advise here… AF_NETLINK sockets need to be added to a network related or avahi interface?

Seems like this should be a request for the snap publisher to request auto-connection of the network-observe interface.

1 Like

Does having AF_NETLINK socket capability imply that the app is able to observe the network, though? If this is a feature required for avahi/mdns then it should be added to that interface, too. While I appreciate that network-observe provides the ability to use AF_NETLINK I’m wary that the implied semantics of allowing network-observe just to access this type of socket might be an overreach.

1 Like

I’m the publisher of this snap! :slight_smile: I could just request network-observe auto-connection, but I’m a bit concerned about suddenly needing new permissions without any new features in the app.

There are lots of different netlink families. Can you put your snap in devmode, then perform: snap run --strace="-e socket -s 1024" your.snap.command and then paste anything with AF_NETLINK?

1 Like

Installed the snap in devmode (which fixes host autodiscovery), then:

$ snap run --strace="-e socket -s 1024" moonlight 2>&1 | grep -i netlink
[pid 3116047] socket(AF_NETLINK, SOCK_RAW|SOCK_CLOEXEC|SOCK_NONBLOCK, NETLINK_KOBJECT_UEVENT) = 22
[pid 3116047] socket(AF_NETLINK, SOCK_DGRAM|SOCK_CLOEXEC, NETLINK_ROUTE) = 24
[pid 3116047] socket(AF_NETLINK, SOCK_RAW|SOCK_CLOEXEC|SOCK_NONBLOCK, NETLINK_KOBJECT_UEVENT) = 24
[pid 3116047] socket(AF_NETLINK, SOCK_DGRAM|SOCK_CLOEXEC, NETLINK_ROUTE) = 28
[pid 3116124] socket(AF_NETLINK, SOCK_DGRAM|SOCK_CLOEXEC, NETLINK_ROUTE) = 28
[pid 3116124] socket(AF_NETLINK, SOCK_DGRAM|SOCK_CLOEXEC, NETLINK_ROUTE) = 28
[pid 3116047] socket(AF_NETLINK, SOCK_DGRAM|SOCK_CLOEXEC, NETLINK_ROUTE) = 37
[pid 3116047] socket(AF_NETLINK, SOCK_DGRAM|SOCK_CLOEXEC, NETLINK_ROUTE) = 38
[pid 3116129] socket(AF_NETLINK, SOCK_RAW|SOCK_CLOEXEC, NETLINK_ROUTE) = 39
[pid 3116124] socket(AF_NETLINK, SOCK_DGRAM|SOCK_CLOEXEC, NETLINK_ROUTE) = 39
[pid 3116124] socket(AF_NETLINK, SOCK_DGRAM|SOCK_CLOEXEC, NETLINK_ROUTE) = 39
[pid 3116124] socket(AF_NETLINK, SOCK_DGRAM|SOCK_CLOEXEC, NETLINK_ROUTE) = 39
[pid 3116124] socket(AF_NETLINK, SOCK_DGRAM|SOCK_CLOEXEC, NETLINK_ROUTE) = 39
[pid 3116124] socket(AF_NETLINK, SOCK_DGRAM|SOCK_CLOEXEC, NETLINK_ROUTE) = 39
[pid 3116124] socket(AF_NETLINK, SOCK_DGRAM|SOCK_CLOEXEC, NETLINK_ROUTE) = 39
[pid 3116124] socket(AF_NETLINK, SOCK_DGRAM|SOCK_CLOEXEC, NETLINK_ROUTE) = 38
[pid 3116124] socket(AF_NETLINK, SOCK_DGRAM|SOCK_CLOEXEC, NETLINK_ROUTE) = 38
[pid 3116124] socket(AF_NETLINK, SOCK_DGRAM|SOCK_CLOEXEC, NETLINK_ROUTE) = 38
[pid 3116124] socket(AF_NETLINK, SOCK_DGRAM|SOCK_CLOEXEC, NETLINK_ROUTE) = 38
[pid 3116047] socket(AF_NETLINK, SOCK_DGRAM|SOCK_CLOEXEC, NETLINK_ROUTE) = 38
[pid 3116047] socket(AF_NETLINK, SOCK_DGRAM|SOCK_CLOEXEC, NETLINK_ROUTE) = 38
[pid 3116124] socket(AF_NETLINK, SOCK_DGRAM|SOCK_CLOEXEC, NETLINK_ROUTE) = 38
(... lots of repeated lines...)
[pid 3116124] socket(AF_NETLINK, SOCK_DGRAM|SOCK_CLOEXEC, NETLINK_ROUTE) = 37
[pid 3116124] socket(AF_NETLINK, SOCK_DGRAM|SOCK_CLOEXEC, NETLINK_ROUTE) = 37
(... some repeated lines...)
[pid 3116047] socket(AF_NETLINK, SOCK_DGRAM|SOCK_CLOEXEC, NETLINK_ROUTE) = 38
1 Like

Between the strace and the denials, it seems to be this that is causing the trouble: socket(AF_NETLINK, SOCK_DGRAM|SOCK_CLOEXEC, NETLINK_ROUTE). This is allowed by ‘network-observe’ and I recommend you plugs that.

I can’t say why Qt 5.14 starting needing this (I suggest looking at the commit history), but from man 7 netlink:

       NETLINK_ROUTE
              Receives  routing  and  link updates and may be used to modify the routing tables (both IPv4 and IPv6), IP addresses, link parame‐
              ters, neighbor setups, queueing disciplines, traffic classes and packet classifiers (see rtnetlink(7)).

It seems plausible that moonlight is using something in Qt to listen for updates for various networking things, which is exactly what network-observe is there for (capability NET_ADMIN would kick in for 'modify’ing these things, which is allowed by network-control).

Thanks! This qtbase commit looks like the culprit, included in Qt 5.11+:

As a follow up, I’ve requested the auto-connection of network-observe: