apparmor errors accessing /dev/gpiochip0 when using libgpiod from within confinement

[Bruno Silva]

We aim to use gpiod, which provides libgpiod2 + cli tools (like gpiodetect, gpioinfo, etc.) on one of our snap applications.
https://git.kernel.org/pub/scm/libs/libgpiod/libgpiod.git/

During some experiments, we realized that no one of the supported interfaces allow access to /dev/gpiochip* to our snap application.
https://snapcraft.io/docs/supported-interfaces

Here is the snappy-debug example when we generated our snap configured with gpio + gpio-control + gpio-memory-control plugs and installed with --dangerous:
= AppArmor =
Time: Jan 27 21:22:47
Log: apparmor="DENIED" operation="open" profile="snap.SNAPNAME.APPNAME" name="/dev/gpiochip0" pid=19145 comm="APPNAME" requested_mask="wr" denied_mask="wr" fsuid=0 ouid=0
File: /dev/gpiochip0 (write)

However, if we install the same snap with --devmode the AppArmor allows access.
= AppArmor =
Time: Jan 27 21:40:14
Log: apparmor="ALLOWED" operation="open" profile="snap.SNAPNAME.APPNAME" name="/dev/gpiochip0" pid=29560 comm="APPNAME" requested_mask="wr" denied_mask="wr" fsuid=0 ouid=0
File: /dev/gpiochip0 (write)

We already tried:
1. add "/dev/gpiochip0 rw," on apparmor rule (/var/lib/snapd/apparmor/profiles/snap.SNAPNAME.APPNAME)
2. Then reload the rule with "sudo apparmor_parser -r /var/lib/snapd/apparmor/profiles/snap.SNAPNAME.APPNAME"
But it didn't work as well (got same apparmor="DENIED").

Note: all snap commands are done with "sudo" (sudo snap try/install/restart/etc.)

[Kyle Nitzsche (knitzsche)]

I am assigning this to Ian because we talked about it and he may know the next process steps. Hmm, looks I can't. I'll ping him.

[Ilya Tatar (itatar)]

Why is this still unassigned? Is there an ETA?
From Kyle's comment it sounds like Ian might know

[Michael Vogt (mvo)]

Sorry for the lack of update on this issue.

Unfortunately this access requires some work on the snapd side to support the new kernel gpio subsystem which is substantially different from the existing gpio userspace.

The good news is that we have it on the roadmap for this cycle and will work on it as one of the early items in the cycle. I cannot yet give a ETA though.

[Ilya Tatar (itatar)]

Thank you for the update. What do other customers that use GPIO do? Is there a workaround?

[Ilya Tatar (itatar)]

The main requirement for our project is to know when a certain GPIO line level changed. It is not good enough to look at the current time of when the user space call back got executed. The callback function in user space must have a timestamp parameter set by the driver that reflects the actual time at which the GPIO level changed. Under most system loads, the accuracy of the reported time stamp shall be within 5ms.