2022-02-07 18:06:28 |
Bruno Silva |
bug |
|
|
added bug |
2022-02-07 19:07:27 |
Bruno Silva |
description |
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 adding "/dev/gpiochip0 rw," on apparmor rule (/var/lib/snapd/apparmor/profiles/snap.SNAPNAME.APPNAME), but it didn't work as well. |
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 adding "/dev/gpiochip0 rw," on apparmor rule (/var/lib/snapd/apparmor/profiles/snap.SNAPNAME.APPNAME), but it didn't work as well.
Note: all snap commands are done with "sudo" (sudo snap try/instal/restart/etc.) |
|
2022-02-07 19:15:43 |
Bruno Silva |
description |
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 adding "/dev/gpiochip0 rw," on apparmor rule (/var/lib/snapd/apparmor/profiles/snap.SNAPNAME.APPNAME), but it didn't work as well.
Note: all snap commands are done with "sudo" (sudo snap try/instal/restart/etc.) |
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 adding "/dev/gpiochip0 rw," on apparmor rule (/var/lib/snapd/apparmor/profiles/snap.SNAPNAME.APPNAME), but it didn't work as well.
Note: all snap commands are done with "sudo" (sudo snap try/install/restart/etc.) |
|
2022-02-07 19:22:39 |
Bruno Silva |
description |
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 adding "/dev/gpiochip0 rw," on apparmor rule (/var/lib/snapd/apparmor/profiles/snap.SNAPNAME.APPNAME), but it didn't work as well.
Note: all snap commands are done with "sudo" (sudo snap try/install/restart/etc.) |
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.) |
|
2022-02-07 20:03:29 |
Ian Johnson |
snapd: status |
New |
Confirmed |
|
2022-02-07 20:03:32 |
Ian Johnson |
snapd: importance |
Undecided |
High |
|
2022-02-07 20:24:01 |
Kyle Nitzsche |
bug |
|
|
added subscriber Kyle Nitzsche |
2022-02-07 21:08:33 |
Ilya Tatar |
bug |
|
|
added subscriber Ilya Tatar |
2022-04-13 16:55:52 |
Kris Linquist |
information type |
Public |
Public Security |
|
2022-04-13 16:56:02 |
Kris Linquist |
bug |
|
|
added subscriber Kris Linquist |
2022-04-14 18:32:20 |
Kris Linquist |
information type |
Public Security |
Public |
|
2022-04-22 20:38:42 |
Ismail Akram |
bug |
|
|
added subscriber Ismail Akram |
2022-05-16 09:36:56 |
Michael Vogt |
snapd: status |
Confirmed |
Triaged |
|
2024-07-23 10:09:37 |
Maciej Borzecki |
snapd: assignee |
|
Maciej Borzecki (maciek-borzecki) |
|
2024-07-23 10:09:59 |
Maciej Borzecki |
snapd: status |
Triaged |
In Progress |
|