We have a core20
-based snap that had hardware-random-control
as a plug so that it could access /dev/hwrng
and that used to work. When we switched over to a core24
-based version, it no longer works and we get a failed to open '/dev/hwrng': Operation not permitted
message. We have confirmed that the interface is connected properly. Also note that this was running on an Ubuntu 24.04 server image.
There are a couple of messages in journald
around the time we get the operation not permitted message:
kernel: audit: type=1400 audit(1746405094.512:151): apparmor="DENIED" operation="capable" class="cap" profile="/snap/snapd/24509/usr/lib/snapd/snap-confine" pid=3168 comm="snap-confine" capability=12 capname="net_admin"
kernel: audit: type=1400 audit(1746405094.512:152): apparmor="DENIED" operation="capable" class="cap" profile="/snap/snapd/24509/usr/lib/snapd/snap-confine" pid=3168 comm="snap-confine" capability=38 capname="perfmon"
but no other messages. snappy-debug
does not indicate anything either.
Any ideas on why this doesn’t work on core24
? Should it be working? I’ve noticed another interface hostname-control
has recently been fixed to work on core24
so if this is another situation that slipped through the cracks?
Since Release New release 2.62 · canonical/snapd · GitHub snapd will place a snap using base core24 in a mandatory device cgroup. Which means that device access will be mediated by the sandbox for every snap using core24+ base, not just the ones that happened to have devices assigned for them though connected interfaces.
However, in your case, having hardware-random-control
plug being connected should enable the snap to access the device.
Can you attach the output of udevadm info /dev/hwrng
?
P: /devices/virtual/misc/hw_random
M: hw_random
U: misc
D: c 10:183
N: hwrng
L: 0
E: DEVPATH=/devices/virtual/misc/hw_random
E: DEVNAME=/dev/hwrng
E: MAJOR=10
E: MINOR=183
E: SUBSYSTEM=misc
This doesn’t look right. Are you sure the interface is connected? Can you paste the output of snap connections <snap-name>
?
Oops, I had the snap installed in devmode
. After re-installing and connecting:
$ snap connections prototype-hwrng-snap
Interface Plug Slot Notes
hardware-random-observe prototype-hwrng-snap:hardware-random-observe :hardware-random-observe manual
And udevadm:
$ udevadm info /dev/hwrng
P: /devices/virtual/misc/hw_random
M: hw_random
U: misc
D: c 10:183
N: hwrng
L: 0
E: DEVPATH=/devices/virtual/misc/hw_random
E: DEVNAME=/dev/hwrng
E: MAJOR=10
E: MINOR=183
E: SUBSYSTEM=misc
Looks to be the same results?
Ah, I see. It’s a bug in snapd interface which worked by accident with old behavior for bases prior to core24. I’ll prepare a PR and it should land in edge soon.
edit: a PR is up: https://github.com/canonical/snapd/pull/15422 we’re targeting 2.69.1/2.69.2 with this one.
1 Like
The PR has landed in master, which means it should be available in the edge channel later today. Can you try to snap refresh --edge snapd
later today. Once it completes, udevadm info /dev/hwrng
output should contain CURRENT_TAGS
entry referencing your snap and you should be able to access /dev/hwrng.
I updated snapd
but didn’t seem to fix the issue. edge
seems to still be back on May 3, 2025. Here is the version string I see: 2.69+g113.58f8e17
. So looks like it hasn’t worked its way through the build yet.
A build was pushed out today. Please give it a go.
Confirmed that this is working with snapd
off of edge - 2.69+g124.20a2c9a
. Thanks for the help!
Thanks for testing. I’ll try to have the fix cherry picked to 2.69.1.