Hardware-random-control interface no longer works in core24-based snap

snapd
1

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?

2

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 ?

3 
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
4

This doesn’t look right. Are you sure the interface is connected? Can you paste the output of snap connections <snap-name> ?

5

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?

6

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
7

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.

8

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.

9

A build was pushed out today. Please give it a go.

10

Confirmed that this is working with snapd off of edge - 2.69+g124.20a2c9a. Thanks for the help!

11

Thanks for testing. I’ll try to have the fix cherry picked to 2.69.1.