fix(docker): fix docker user permission

[SteveHawk]

In the previous dockerfile fix (#82), I made an oopsie and didn't properly set user's permission. When connected to external devices such as an AIOC, it would complain about no permission to access unless I run the service in root.

graywolf  | graywolf-modem: ConfigurePtt: build driver for channel 1 (cm108): open /dev/hidraw8: EACCES: Permission denied
graywolf  | graywolf-modem: failed to resolve output device_id=2 (plughw:CARD=AllInOneCable,DEV=0): output device not found: plughw:CARD=AllInOneCable,DEV=0
graywolf  | graywolf-modem: start_audio failed (input device not found: plughw:CARD=AllInOneCable,DEV=0), retrying in 500ms
graywolf  | graywolf-modem: failed to resolve output device_id=2 (plughw:CARD=AllInOneCable,DEV=0): output device not found: plughw:CARD=AllInOneCable,DEV=0
graywolf  | graywolf-modem: start_audio failed: input device not found: plughw:CARD=AllInOneCable,DEV=0

So this PR fixes the problem by including the user in audio (access audio devices like /dev/snd), dialout (access serial ports like /dev/ttyUSB*) and plugdev (access removable devices like /dev/hidraw*) group.

(More info on system groups: https://wiki.debian.org/SystemGroups)

On Linux systems, the best practice is usually using udev rules to dynamically enable user's permission to access certain devices, because adding user to system groups would mean permission to access all devices in that category. However udev isn't available in docker, and since only target devices are passed in anyways, I think adding user to these groups is reasonable from a security standpoint.

At this moment, including these three groups (audio,dialout,plugdev) is enough for my use case, but I'm not sure if others would need more. I guess we can add more if someone complains.

Also there's a potential problem I stumbled upon in this stackoverflow answer, where devices can be owned by different groups in different distro, so this fix can only guarantee to work on debian family distros, others like arch might break. (uucp group has different gid between arch and debian, so we can't just simply include that.) I would say this is probably good enough for now, let's fix this when someone complains in the future.

[chrissnell]

There's not a standard for device ownership groups across all Linux distros. I think a better solution is to run a shell script that sources /etc/os-release and then uses a case statement on ID to choose which group(s) to chown with.

[SteveHawk]

There's a problem with that approach: we don't really know user's distro during build time. Script will always read Debian because that's the base image's distro.

If we set it at runtime, then another problem: we're running non privileged user, whom do not have the permission to set it's own group. If we use root, then we don't really need to set permission because we can already access everything.

[SteveHawk]

Did a bit more research on this topic, and permission management is just a naughty little bastard.

Checked a few of the most popular distros out there including debian, arch, RHEL/fedora, gentoo and such, and I only find debian and arch have proper documentations on these system groups, no mention on other distros' wikis, only some sparse info here and there. With these limited knowledge, it seems like most distros use audio group for /dev/snd devices. Most distros use dialout group for serial devices, except arch which uses uucp. As for /dev/hidraw* devices, debian and maybe a few others provide plugdev, and arch simply does not support using group permission to access it, only udev.

Oh and these groups might have different group ids under the hood. So it's simply impossible to support all.

So I can think of three options to solve this:

1. Use non-priviledged user with no permission. Document that it will require manual permission settings to use any external devices, such as fiddle with cgroup rules or udev rules, or run container as root.
2. Use the group method this PR proposes, and document that it will only work out-of-the-box on debian and debian-based distros, and may require manual setup on other distros. Since a lot of people use debian or debian-based distros (like ubuntu, popos, raspberrypi os, armbian and so on), this should cover a lot of people.
3. Use root user in container. Will run anywhere without permission issues, but less safe.

Personally I still prefer option 2. Because for option 1, given how obscure it is to set cgroups rules or udev rules, most people probably will just use root user anyways because it's way simpler, and now it's as insecure as option 3. Option 2 is a middle ground providing safer option for the most popular distro family.