In debugging an issue, I discovered that devmode snaps that connect interfaces that specify udev tagging will have files created by snapd in /etc/udev/rules.d for the snap, when they shouldn’t be, resulting in EPERM denials for devices in /dev that aren’t covered by connected policy.
The solution is whenever installing/refreshing a snap to devmode to remove any files for the snap in /etc/udev/rules.d,then call uevadm.
To unblock devmode developers, you should be able to:
$ sudo rm -f /etc/udev/rules.d/70-snap.yoursnap.rules
$ sudo udevadm control --reload-rules
$ sudo udevadm trigger
$ sudo sh -c "echo 'a *:* rwm' > /sys/fs/cgroup/devices/snap.yoursnap.yourcmd/devices.allow"
with the above commands, the device cgroup is disabled and the devmode snap should no longer be blocked. Importantly, snapd may regenerate the policy in various situations (eg, if you reboot, install, refresh snaps), so you might have to redo the above.
Note, since this is a devmode snap, the devmode snap would be allowed to do all of the above.
@jenny.murphy - any interface that grant access to files in /dev now specify udev tagging. In snapd 2.27 and earlier, use of udev tagging/device cgroups was not consistent. This caused bugs with snaps that connected multiple interfaces with access to /dev with at least one that used udev tagging (eg, io-ports-control) and at least one that did not (eg, opengl). This would result in the device cgroup being activated (eg, /dev/ports for io-ports-control added to cgroup) but not all devices being added to it (eg, /dev/dri/card0 from opengl not added), resulting in EPERM denials for those devices not added to the cgroup. In 2.28, all interfaces that allow access to /dev now use udev tagging so that all the devices are available when a device cgroup is in effect.
Another workaround for devmode would be to disconnect all the interfaces that give access to /dev, yes.