You need to plugs physical-memory-observe and either be root or in the kmem group.
If you meet all those criteria, there might be a dmidecode or kernel bug since physical-memory-observe is supposed to āwith STRICT_DEVMEM=y, allow reading /dev/mem for read-only access to architecture-specific subset of the physical address (eg, PCI, space, BIOS code and data regions on x86, etc).ā If you feel this is the case, perhaps using base: core18 would get you a dmidecode that would work on that kernel.
I currently install my snap with --devmode and itās already using base: core18. Does devmode requires plugs anyway, or does it bypass this mechanism completely?
ādevmode just turns all denials into allowances but you still get an audit log entry for each and every access to the interface until you connect it.
so to avoid flooding your journal you should still connect as many interfaces as you can, even in devmode (also makes debugging easier if you dont have to fish out the relevant error messages from a sea of pointless āALLOWEDā messages )
I feel obligated to point out I know of the existence of a snap that works in strict mode with the plugs, but doesnāt work in devmode with the same plugs, so there could be dragons thereā¦
Also Iāll say that snap was a complicated Qt snap with ROS stuff so probably much different from this
Important note before I go on: after testing the following, I realized that this issue only seems to happen with the armhf and arm64 builds of the snap, not the amd64 buildā¦
I suspect this is related to STRICT_DEVMEM=y in the kernel config which allows reading /dev/mem for read-only access to architecture-specific subset of the physical address (eg, PCI, BIOS code and data regions on x86, etc). Itās plausible that dmidecode needs an update for the newer kernel. Perhaps if you havenāt already, you should use ābase: core18ā for qabro and then stage-packages dmidecode, which will now come from Ubuntu 18.04 and hopefully work with the newer kernels.
beyond what jamie said, you should generally be putting the sudo on the first command (before snap run... ) the way you call it abve execs sudo from inside the snap shell env which might or might not cause unexpected resultsā¦
Iāve updated core: base18 in my snapcraft.yaml a while ago, and am already staging dmidecode from there, so my snap is already running dmidecode 3.1.
Just for the record, Iām trying to run this on a Raspberry Pi 3 with the latest Ubuntu Core 18 I found on ubuntu.com. uname -a returns 4.15.0-1052-raspi2 #56-Ubuntu SMP PREEMPT Tue Nov 26 15:37:05 UTC 2019 armv7l armv7l armv7l GNU/Linux
Thanks for the feedback @ogra. I tried the following:
pieq@localhost:~$ sudo snap run --shell qabro
root@localhost:/home/pieq# /snap/qabro/x1/usr/sbin/dmidecode -s system-manufacturer
/dev/mem: Operation not permitted
/dev/mem: Bad file descriptor
root@localhost:/home/pieq# /snap/qabro/x1/usr/sbin/dmidecode -V
3.1
root@localhost:/home/pieq# /snap/qabro/x1/usr/sbin/dmidecode
# dmidecode 3.1
Scanning /dev/mem for entry point.
/dev/mem: Operation not permitted
/dev/mem: Bad file descriptor
Seems like Iām getting the same result
Also, I was originally using sudo inside my snap, because my snap application is running some pretty basic stuff, and only requires sudo for the dmidecode commandā¦ If I run my snap as sudo, it creates other problems (if I remember correctly, havenāt tried that in a while).
Iāve recently built a new version of my app, and this version works fine on UC18 (amd64, both in a VM and on a x86 device)ā¦ I donāt think Iāve changed anything regarding dmidecode in my code, so it might be a change in the UC18 images???
Anyway, I guess this issue can be considered solved
)
