apparmor errors accessing /dev/gpiochip0 when using libgpiod from within confinement
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
snapd |
In Progress
|
High
|
Maciej Borzecki |
Bug Description
We aim to use gpiod, which provides libgpiod2 + cli tools (like gpiodetect, gpioinfo, etc.) on one of our snap applications.
https:/
During some experiments, we realized that no one of the supported interfaces allow access to /dev/gpiochip* to our snap application.
https:/
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=
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=
File: /dev/gpiochip0 (write)
We already tried:
1. add "/dev/gpiochip0 rw," on apparmor rule (/var/lib/
2. Then reload the rule with "sudo apparmor_parser -r /var/lib/
But it didn't work as well (got same apparmor="DENIED").
Note: all snap commands are done with "sudo" (sudo snap try/install/
description: | updated |
description: | updated |
description: | updated |
Changed in snapd: | |
status: | New → Confirmed |
importance: | Undecided → High |
information type: | Public → Public Security |
information type: | Public Security → Public |
Changed in snapd: | |
assignee: | nobody → Maciej Borzecki (maciek-borzecki) |
status: | Triaged → In Progress |
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.