description: Resources is a simple yet powerful monitor for your system resources and processes, written in Rust and using GTK 4 and libadwaita for its GUI. It’s capable of displaying usage and details of your CPU, memory, GPUs, NPUs, network interfaces and block devices. It’s also capable of listing and terminating running graphical applications as well as processes.
upstream-relation: no relation with upstream, which only provides official support for Flatpak
interfaces:
process-control:
request-type: auto-connection
reasoning: support application termination feature. Without this interface the application will be missing a basic feature, and create a misleading and confusing experience for users.
hardware-observe:
request-type: auto-connection
reasoning: access to /sys and /proc is needed for system monitoring. Without this access the application would be missing basic features (displaying information about running processes).
system-observe:
request-type: auto-connection
reasoning: allow read access to additional data in /proc. For example, displaying per-process GPU usage for Intel and AMD GPUs requires access to /proc/PID/fdinfo, which is provided by system-observe starting in snapd 2.75 (link).
desktop-launch:
request-type: auto-connection
reasoning: enables access to app desktop files for other snaps on the system. This allows icons to be displayed beside applications, which is a feature of the resources application. Without this interface, the user experience is poor as resources will show a generic puzzle piece icon beside each snap application running on the system.
usr-share:
request-type: auto-connection
reasoning: this plug uses the system-files interface to access icon data for system packages (i.e. deb packages) at /var/lib/snapd/hostfs/usr/share. The reasoning is similar to desktop-launch. Without this access, a running application from a debian package will show a generic puzzle piece icon, which is a poor user experience as it’s harder to read and navigate the application view provided by resources.
Note that I originally uploaded this snap to the store a few months ago and it failed manual review due the requirement for super-privileged interfaces. Since resources is a system monitoring tool, it needs privileged access to a user’s system, so these are legitimate needs in order for the application to function properly as a snap.
Given the snap’s functionality, the process-control, hardware-observe, and system-observe interfaces make sense to me (#voteFor).
As for system-files and desktop-launch, these are both super-privileged interfaces. To be granted auto-connection, we require publisher vetting. In order to successfully vet a publisher, we need to verify their connection to the upstream project and this isn’t currently possible since you are not part of the upstream team.
However, based on the reasoning provided, xdg-desktop-portals might be helpful for your use case. They allow desktop applications to access resources outside of their sandbox securely. You might want to see if these can address your snap’s requirements instead.
If you need any further assistance, please let us know
This is a +1 (#voteFor) from me for granting auto-connect for the process-control, hardware-observe, and system-observe interfaces given the snap’s advertised functionality.
I agree with @yomonokio above for the system-files and desktop-launch interfaces, the described functionality does not justify the expansive privileges granted by these interfaces, and they can not be installed without successful publisher vetting.
I agree desktop-launch and access to /usr/share are not required for the snap to be functional and they are perhaps too privileged for the use case. However, considering that upstream project looks mature and the publisher is vetted as a canonical employee, I think granting manual connection would be appropriate in this case.
@wfrench does it sound like a reasonable trade-off?
I looked into portals. I am using the gnome snapcraft extension so portals support should be enabled for Resources since it uses GTK4 (it should be transparent if I’m understanding the docs correctly), but that is not my experience as Resources cannot access app icon data for either snaps or debs installed on the system. I am not familiar enough with portals to understand why, exactly. Maybe I can find some time to dig a bit deeper but if you have any ideas or suggestions to point me in the right direction that would be amazing.
It’s not ideal as most casual users will not be aware of these interfaces and how to go about enabling them, but it’s definitely better than not having access to the interfaces at all.
To give you an idea of the difference, here is a screen shot with the desktop-launch and system-files interfaces connected:
It’s just a very underwhelming experience without the interfaces connected as all the apps get lumped together into a single “System Processes” category, whereas with the interfaces connected it’s a much richer presentation of what is happening on a user’s system.
If the out-of-the-box view (without autoconnections) does not show a user the apps they know are actually running, it doesn’t make a good first impression and they are less likely to trust the application.
I understand there are security concerns, but this seems to sacrifice a lot on the user experience. Maybe I need to have a deeper look at portals to see if this is feasible, but I’m concerned this will actually require me to modify the application to make the appropriate API calls. If it’s transparent and I just need to turn a few more knobs in the snap build to enable support, then I’m very open to this approach.
For deb applications, I think we can grant the auto-connection to a limited scope (/usr/share/icons and /usr/share/pixmaps). This won’t work for all applications (as debian packaging policy also support other application specific locations), but in practice I believe this should cover the bast majority of cases. Perhaps this is a good compromise solution to start with.
Regarding desktop-launch, this looks really too powerful. Looking at the [interface implementation](snapd/interfaces/builtin/desktop_launch.go at master · canonical/snapd · GitHub), maybe granting read access to /var/lib/snapd/desktop/icons/ via system-files should work. It does not seems to be populated on my installation though. I don’t know if this might be a bug on snapd, if so it would be worth fixing it and limit access to this directory
For desktop-launch is it granting the ability to launch other snaps that is the concern? Or is it also granting read access to metadata from other snaps?
I took a look at an example .desktop file on my system and it points to an icon inside its own snap:
So really what Resources needs is only the ability to read metadata from other snaps on the system. If I used the system-files interface to accomplish this, would that be acceptable or is this also too permissive?
For desktop-launch is it granting the ability to launch other snaps that is the concern? Or is it also granting read access to metadata from other snaps?
I think it is a bit of both. Granting access to /snaps may potentially be a concern when adding brand store snaps to the mix. However, perhaps it is ok to grant it in this case. @pedronis What do you think?
It’s always a bit of a balancing act between making things work smoothly and keeping the security tight, especially with brand store snaps involved. Hopefully, we can find a middle ground that keeps things secure without making it too difficult for users.
