Mission Center auto-connection requests

kicsyromy · September 30, 2024, 6:38am

Hello,

Mission Center is a system monitoring application that allows a user to view system resource utilization, view running applications and processes, as well as view and control system services (SystemD and OpenRC).

In order to provide a good out of the box experinece to my users I would like to enable auto-connection to the following plugs:

hardware-observe
network-manager
network-observe
process-control
system-observe

hardware-observe: The application monitors devices present on the user’s system, this includes CPU, RAM, storage devices, network devices, GPUs and fans.

network-manager: The application connects to org.freedesktop.NetworkManager on the system bus to query information about each detected network interface

network-observe: The application uses the APIs provided by the <net/if.h> header to detect available network interfaces.

process-control: The application allows a user to not only view running processes but also send a TERM or KILL signal to them

system-observe: The application allows a user to only view running processes by PID, name, executable, parent, etc.

Thank you!

jslarraz · September 30, 2024, 2:51pm

I’m definitively for granting auto-connection to hardware-observe, network-manager, network-observe and system-observe.

Regarding process-control, it does not feel required for most usecases. I would prefer to go with manual connection. Then, the first time a user tries to kill a process you can detect whether the plug interface is connected and prompt the user to manually connect it if not. Would that work for you?

kicsyromy · September 30, 2024, 3:49pm

Thanks for the quick reply.

Yes, that’s a fair compromise. I can work with that.

soumyaDghosh · September 30, 2024, 6:28pm

I don’t think that’d be good for UX.

soumyaDghosh · September 30, 2024, 6:30pm

Also, granting desktop-launch to this snap, would make the icons of the snaps show up. @kicsyromy please add that also in this list.

kicsyromy · September 30, 2024, 7:29pm

@jslarraz would that be something you’d be willing to grant to auto-connect?

alexmurray · October 1, 2024, 12:18am

Regarding network-manager would it be possible instead to use network-manager-observe The network-manager-observe interface | Snapcraft documentation?

Finally, I do not think auto-connect of desktop-launch is appropriate - this interface is designed for things like an entire desktop session or an app store that wants to provide the ability to launch other snaps.

cav · October 1, 2024, 12:54am

I agree with @jslarraz with the process-control interfaces and in the meantime whilst waiting for more info about network-manager-observe,

+1 from me as well for auto-connecting hardware-observe, network-observe and system-observe

kicsyromy · October 1, 2024, 5:37am

@alexmurray network-manager-observe doesn’t seem to be enough, no network interfaces show up.

I need to see what the difference is between network-manager and network-manager-observe.

EDIT: After a bit of debugging this is the log that I see:

Failed to get device info for "enp6s18": GDBus.Error:org.freedesktop.DBus.Error.AccessDenied: An AppArmor policy prevents this sender from sending this message to this recipient; type="method_call", sender=":1.244" (uid=1000 pid=13450 comm="/snap/mission-center/x1/usr/bin/missioncenter" label="snap.mission-center.mission-center (enforce)") interface="org.freedesktop.NetworkManager" member="GetDeviceByIpIface" error name="(unset)" requested_reply="0" destination=":1.10" (uid=0 pid=1516 comm="/usr/sbin/NetworkManager --no-daemon" label="unconfined")

Apparently access to the GetDeviceByIpIface is not allowed when using network-manager-observe, this seems unintentional to me. Any ideas @alexmurray @cav?

jslarraz · October 1, 2024, 8:18am

Unless I’m missing something it looks completely unintentional to me. GetDeviceByIpIface looks like a good candidate to be part of network-manager-observe.

soumyaDghosh · October 1, 2024, 8:18am

Can’t find any interface that supports it in snapd.

jslarraz · October 1, 2024, 8:24am

Oh, you are right, network-manager is not allowing GetDeviceByIpIface either. There must be other difference

kicsyromy · October 1, 2024, 8:56am

From the application POV this is the thing that prevents the interfaces from showing up in the UI.

Switching to network-manager the log no longer shows up and the interfaces are visible again.

soumyaDghosh · October 1, 2024, 9:15am

This is interesting, let me check

soumyaDghosh · October 1, 2024, 9:19am

github.com

canonical/snapd/blob/master/interfaces/builtin/network_manager.go#L202


      
          dbus (receive, send)
              bus=system
              path=/org/freedesktop/NetworkManager{,/**}
              interface=org.freedesktop.NetworkManager*
              peer=(label=unconfined),
          
          # Allow traffic to/from org.freedesktop.DBus for NetworkManager service
          dbus (receive, send)
              bus=system
              path=/org/freedesktop/NetworkManager{,/**}
              interface=org.freedesktop.DBus.*
              peer=(label=unconfined),
          
          # Allow ObjectManager methods from and signals to unconfined clients.
          dbus (receive, send)
              bus=system
              path=/org/freedesktop
              interface=org.freedesktop.DBus.ObjectManager
              peer=(label=unconfined),
          
          # Allow access to hostname system service

I think this is how GetDeviceByIpIface is working. But, I am also seeing another error

Failed to connect to the D-Bus session bus, and set up monitoring: An AppArmor policy prevents this sender from sending this message to this recipient; type="method_call", sender=":1.284" (uid=1000 pid=81578 comm="missioncenter-gatherer" label="snap.mission-center.mission-center (enforce)") interface="org.freedesktop.DBus.Monitoring" member="BecomeMonitor" error name="(unset)" requested_reply="0" destination="org.freedesktop.DBus" (bus) (missioncenter-gatherer:81578):

This should not have occured.

kicsyromy · October 1, 2024, 9:27am

The BecomeMonitor error is expected, and has no adverse effects. It is only used when running as a Flatpak.

kicsyromy · October 2, 2024, 4:03am

@alexmurray @cav @jslarraz Are we all in agreement about hardware-observe, network-observe and system-observe being acceptable for auto-connection?

With regards to network-manager vs network-manager-observe what do you think is the next step here? Do you have any suggestions?

Thank you!

alexmurray · October 2, 2024, 4:10am

If the current network-manager-observe interface is not able to meet the needs of mission-center, then I think it is fine to consider still using network-manager, even if it provides more than is necessary. In the future, if the required methods etc do get added to the -observe interface in snapd then mission-center could be reworked to use this instead. Out of interest, how does the mission-center behave if the network-manager interface is not connected at all?

+1 from me for auto-connection of hardware-observe, network-observe and system-observe. Note there is prior precedence for auto-connect of process-control for similar process monitoring/interaction snaps (Auto-connection requests for htop) so +1 for auto-connect of process-control too. And finally, +1 for auto-connect of network-manager but I would still be interested to know what the behaviour is when this is not available, since perhaps manual connection may be more appropriate here.

kicsyromy · October 2, 2024, 4:39am

Thanks!

When network-manager is not connected, or network-manager-observe is used, the application does not show any network interfaces.

If you look at this screenshot you can see how network interfaces show up in the app.

This part is effectively missing.

Hope this helps explain the impact.

alexmurray · October 2, 2024, 5:08am

Thanks for the extra info - this looks like a standard piece of functionality then so network-manager should be auto-connected then IMO.