Interface configuration for sys dmi product_name

rj1972 · August 24, 2021, 2:14pm

Our organisation has a customised core20 image deployed across two different models of NUC. I want to amend our config snap to identify the device name by querying /sys/devices/virtual/dmi/id/product_name, so I’ve included the following couple of lines in the snap’s configure hook:

    deviceModel=$(cat /sys/devices/virtual/dmi/id/product_name)
    snapctl set device.model="$deviceModel"

which works as expected running in devmode, but not when confined.

I then followed @ogra’s advice from here (Interface for sys dmi info) which suggests that either fwupd or browser_support are the interfaces to provide access to this location; however I can’t get either to work. As an example I’m specifying the plugs to use like so:

plugs:
  ...
  fwupd:

When I install the snap, as expected it doesn’t automatically connect the fwupd plug:

$ snap connections my-config
Interface           Plug                          Slot                 Notes
fwupd               my-config:fwupd               -                    -
network-observe     my-config:network-observe     :network-observe     gadget

but when I try to manually connect it I get this response:

$ snap connect my-config:fwupd
error: snap "snapd" has no "fwupd" interface slots

By contrast using browser_support doesn’t error out and appears to connect the interface correctly using the above approach - but it doesn’t seem to give the access I need to /sys/devices/virtual/dmi/id/product_name. Can anyone shed any light on what I’m doing wrong?

ogra · August 24, 2021, 2:24pm

well, using either fwupd (while not using fwupd) or browser-support (while not being a browser) are rather hacks/workarounds … the proper solution would really be to add the two lines from:

github.com

snapcore/snapd/blob/master/interfaces/builtin/browser_support.go#L179


/sys/devices/**/revision r,
/sys/devices/**/serial r,
/sys/devices/**/vendor r,
/sys/devices/system/node/node[0-9]*/meminfo r,
# Allow getting the manufacturer and model of the
# computer where Chrome/chromium is currently running.
# This is going to be used by the upcoming Hardware Platform
# extension API.
# https://chromium.googlesource.com/chromium/src.git/+/84618eee98fdf7548905e883e63e4f693800fcfa
/sys/devices/virtual/dmi/id/product_name r,
/sys/devices/virtual/dmi/id/sys_vendor r,
# Chromium content api tries to read these. It is an information disclosure
# since these contain the names of snaps. Chromium operates fine without the
# access so just block it.
deny /sys/devices/virtual/block/loop[0-9]*/loop/backing_file r,
deny /sys/devices/virtual/block/dm-[0-9]*/dm/name r,
# networking
/run/udev/data/n[0-9]* r,

into the hardware-observe interface and have your app actually use this interface … (i have moved your post to the snapd category, so the snapd team sees this (and hopefully adds these two lines for us)

regarding the “why does it not work ?” … did you explicitly add the plugs to the configure hook in your snapcraft.yaml ?

similar to:

github.com

ogra1/zoom-snap/blob/master/snap/snapcraft.yaml#L51


      - opengl
      - pulseaudio
      - removable-media
      - screencast-legacy
      - screen-inhibit-control
      - system-observe
      - unity7
      - wayland
      - x11
hooks:
  configure:
    plugs:
      - desktop
      - system-observe
layout:
  /sbin/killall5:
    bind-file: $SNAP/sbin/killall5
  /usr/bin/lscpu:
    bind-file: $SNAP/usr/bin/lscpu

rj1972 · August 24, 2021, 2:57pm

Thanks for the response - your suggestion that those lines are added to hardware-observe sounds sensible to me!

I didn’t previously add either plug explicitly to the configure hook (just at the top level in my snapcraft.yml, as I’ve done previously with a couple of other plugs that I’m using in the configure hook). Anyhow, I’ve just tried your suggestion using browser-support, but unfortunately it still doesn’t work - it just sets my snap’s device.model value to “”.

ogra · August 24, 2021, 3:27pm

to just ask the obvious,

cat /sys/devices/virtual/dmi/id/product_name

actually returns something if you run it just from the shell ?
(it looks like the interface connection is fine with browser-support connected if you don’t get an error or any apparmor denials in the journal output)

rj1972 · August 24, 2021, 3:52pm

Yes, it does - but always worth checking the obvious

As a matter of fact I am getting an apparmor denial:

[11237.997471] audit: type=1400 audit(1629816489.063:2671): apparmor="DENIED" operation="open" profile="snap.my-config.hook.configure" name="/sys/devices/virtual/dmi/id/product_name" pid=4544 comm="cat" requested_mask="r" denied_mask="r" fsuid=0 ouid=0

The plug is definitely connected though, hence my confusion:

$ snap connections my-config
Interface              Plug                                 Slot                    Notes
browser-support        my-config:browser-support            :browser-support        manual

ijohnson · August 25, 2021, 11:56pm

To be clear, the fwupd interface is not implicit, so it is not provided by the snapd / core snaps, and you would need to connect the fwupd plug you have in your snap to some other snap which is providing the fwupd slot.

The browser-support interface is implicit however, so the plug can always be connected to the snapd / core snap slots. However to get the sys/devices/virtual/dmi/id/product_name access through the browser-support interface, you need to use the allow-sandbox: true attribute with the plug declaration in your snap as in :

plugs:
  browser-support-with-sandbox:
    allow-sandbox: true
hooks:
  configure:
    plugs:
      - browser-support-with-sandbox

though I agree with @ogra the ideal solution here is just to move that read access to something like hardware-observe instead.

ijohnson · August 25, 2021, 11:58pm

… and here you go, a PR adding those accesses to hardware-observe: https://github.com/snapcore/snapd/pull/10681