The gpio-control interface that snapd provides allows access to the sysfs interface for GPIO, that interface has been deprecated for a while (sysfs interface not snapd’s). In our case we are using libgpiod, which uses /dev/gpiochip* to control the GPIO pins. Clearly there is no snapd interface that allows access to that path. So I patched gpio_memory_control.go interface and added below line to it
/dev/gpiochip[0-9]* rw,
Previously when I was trying to access /dev/gpiochip0 I was getting “Permission denied” and dmesg logs would clearly show the reason. Now after patching snapd, I am still not able to access the /dev/gpiochip0 and get Operation not permitted instead.
It’s clear my patch to snapd made some changes, but why am I not able to access that path still. Outside snap environment I can access path but not from within. --devmode also works
Some details about the system: This is RaspberryPI CM4 based board.
Do note that patch works fine on a iMX8MP based board and the issue only happens with CM4 based board. Both systems are running Yocto. Seems like Snapd/Apparmor are doing something weird here ?
The earlier EACCESS was caused by apparmor. The EPEMR is coming from device cgroup contoller. Most likely you need to update the patch to tag the /dev/gpiochip* for a given snap. In short, you need to add a udev snippet that would match the device (eg by SUBSYSTEM="gpio", KERNEL="gpiochip*' or something similar) and add a TAG+="snap_<yoursnap>_<yourapp>. There should be a bunch of examples under insterfaces/builtin, eg the opengl interface.