Auto-connect request for aboutmydevice

To make the review of your request easier, please use the following template to provide all the required details and also include any other information that may be relevant.


  • name: aboutmydevice
  • description: AboutMyDevice is a free cross-platform app for viewing local device, operating system, processor, battery, network, and display information. The Linux build (like on other platforms) is strictly confined and read-only: it only displays information about the local machine and never modifies system state.
  • snapcraft: Private
  • upstream: PRIVATE
  • upstream-relation: I’m the author and sole developer/publisher
  • interfaces:
    • hardware-observe:
      • request-type: auto-connection
      • reasoning: Core functionality of the app. Used (read-only) to show the device model from /sys/class/dmi/id/{product_name,product_version,board_name} (and /proc/device-tree/model on ARM), per-core CPU topology and frequencies from /sys/devices/system/cpu/, and graphics adapter details via lspci and /sys/class/drm/. Without this connection the Device, Processor, and Display tabs are (mostly) empty.
    • system-observe:
      • request-type: auto-connection
      • reasoning: Core functionality of the app. Used (read-only) to display operating system and processor details from /proc (e.g. /proc/cpuinfo, kernel version) via the device_info_plus plugin (plugin link)
    • network-manager-observe:
      • request-type: auto-connection
      • reasoning: The Network tab uses the connectivity_plus plugin (plugin link), which queries NetworkManager over D-Bus (read-only/observe — no settings access) to report the active connection type (Wi-Fi/Ethernet).
    • system-backup:
      • request-type: auto-connection
      • reasoning: Inside a strictly confined snap, /etc/os-release describes the core24 base rather than the host distribution. The app reads only /var/lib/snapd/hostfs/etc/os-release (falling back to /var/lib/snapd/hostfs/usr/lib/os-release) so the OS tab can show the user’s actual distribution name and version. No other host paths are accessed and nothing is written.

The snap is already published in the store at https://snapcraft.io/aboutmydevice

This app’s purpose is to display device information, so these observe-style interfaces are its core functionality rather than optional extras; without auto-connection, first-run users see largely empty tabs and may assume the app is broken. All access is read-only.

This request has been added to the queue for review by the @reviewers team.

Hi @ndl_linux,

Given the functionality of the snap, +1 from my side for granting auto-connection to hardware-observe, system-observe and network-manager-observe interfaces. Since, system-observe already provides access to /var/lib/snapd/hostfs/etc/os-release and system-backup provides broader read only access to the host filesystem, I think that won’t be necessary for the snap.

Kindly let us know if you think otherwise.

hi @ndl_linux , let us know if you can provide more info on @shishirsub10 ‘s question

Thanks both @shishirsub10 @0xnishit, and special thanks @shishirsub10 for catching that. I checked the system-observe AppArmor policy and it already grants the path for host OS info: /var/lib/snapd/hostfs/etc/os-release

I’m withdrawing the system-backup request and will remove the plug from the snap. To confirm, that leaves auto-connection requested for hardware-observe, system-observe, and network-manager-observe only. Thanks for the quick review!

+1 from my side for granting auto-connection to hardware-observe, system-observe and network-manager-observe interfaces.

thanks

Hi @ndl_linux,

+2 votes for, 0 votes against, granting auto-connect of interface hardware-observe, system-observe and network-manager-observe to snap aboutmydevice . This is now live.

1 Like