I don’t think we want to limit Gladys container access to the machine.
I remind you that the Raspbian Gladys image must work throughout the user’s Raspberry Pi lifecycle.
Imagine the user installs Gladys in 2020 and changes their Pi in 2030. Over 10 years, if we add features, new integrations are developed in Gladys, the Raspbian image must be evolvable and all dongles plugged in must be managed by Gladys.
If we have to ask the user to reinstall Gladys every other day, then we have failed our mission.
I quote a post I wrote on another topic:
Why do we use Docker?
In Gladys 3, I remind you that we ran Gladys directly on the machine, without Docker, so Gladys had full access to the machine.
In Gladys 4, we use Docker to facilitate packaging, deployment, and updating Gladys instances. Given that we are in embedded systems, we need to access devices (USB, GPIO, Camera Pi via the camera bus, for example), it makes perfect sense to give Gladys full access to the machine, as would be the case if we just ran the program directly on the Raspberry Pi.
We are not at all in the Docker usage of a cloud provider that would want to isolate the execution of untrusted code, limit access to the physical machine, and limit the resource usage of a third-party user.
Here, the user runs on their own machine, alone, an embedded program that makes intensive use of external devices and hardware. On the contrary: we want to take advantage of the super capabilities of the Raspberry Pi, and have the same features as if we ran Gladys directly on the host like most programs do.
Trying to limit the container’s access to the Pi doesn’t make sense and doesn’t add security…
We need to think as long-term as possible, and put the user experience first.
What’s the problem with exposing /dev? Gladys is there to do home automation, not to stay locked in a container ^^