Device cgroup is applied to devmode and classic snaps

snapd
1

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.

UPDATE: this also applies to classic snaps.

2

I forgot to mentioned that this is affecting a customer.

3

Since no one jumped on it over night, I’ll take a look at this.

4

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.

5

FYI, https://github.com/snapcore/snapd/pull/4114

1 Like
6

Thanks @jdstrand for fixing this bug! Given that this is not a new regression I would suggest the following action:

  • schedule a new 2.29.1 with this fix (and the fixes in PR#411{5,6}) for Monday in a week (13.11)
  • release 2.29 from candidate as planned on Monday (6.11).

What do you think?

7

Just to clarify the type of snaps that are affected by this bug : what interfaces specify udev tagging ?

If running in development mode, could another workaround (which WILL be maintained across reboots) be to NOT connect that interface.

8

From my perspective, that is fine, but @awe would need to comment on behalf of the customer.

9

@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.

1 Like