Interface configuration for sys dmi product_name

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:


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?

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:

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:

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 “”.

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)

Yes, it does - but always worth checking the obvious :slightly_smiling_face:

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="" 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

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 :

    allow-sandbox: true
      - 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.

… and here you go, a PR adding those accesses to hardware-observe: