I think this broke the Docker builds.

Yes, you're right. I removed creation of input group from DEB/RPM postinstall script since udev rule makes it unnecessary. However, Docker images still try to create a lizard user and add it to input group:

useradd -lm -d ${HOME} -s /bin/bash -g "${PGID}" -G input -u "${PUID}" "${UNAME}"

Unfortunately, Debian/Ubuntu images don't have input group by default. That's why the build fails.

In this case I suggest to create lizard user without input group. Normally, users created in Docker containers don't have access to host devices. But as I see, UID and GID of lizard user are set to match UID and GID of host user. This means that if we properly install udev rule on the host, both host user and lizard user should be able to access Sunshine virtual devices. No input group needed.

Applied the changes in the commit below.

@ABeltramo does this seem like a sane approach to you?

This is a tricky one and would have to be tested, but if the udev rules are going to give group access to the specified GID and that's the same group mapped to the container, it should work.
Am I getting the approach here right?

@ABeltramo Basically yes, except that udev rules are going to give user access to the specified UID and that's the same user mapped to the container. Groups are not involved at all. The whole point of this PR is to avoid group permissions and rely on user permissions exclusively. It is intended to work in the following way:

1. We install udev rule on the host.
2. udev rule sets up ACL on /dev/uinput to grant R/W access to user on the host. Here is how permissions look on my system:

$ getfacl /dev/uinput
getfacl: Removing leading '/' from absolute path names
# file: dev/uinput
# owner: root
# group: input
user::rw-
user:kodemeister:rw-
group::rw-
mask::rw-
other::---

Please note the line user:kodemeister:rw-. This means that user kodemeister has R/W access to /dev/uinput in addition to standard Unix user/group/other permissions.
3. We run Docker container and mount /dev directory from host to container (-v /dev:/dev).
4. We create a new lizard user in the container and assign it the same UID as kodemeister user on the host.
5. As a result, lizard user should have access to /dev/uinput without messing with group permissions.

Indeed, this needs to be tested. Are there any instructions on running dockerized Sunshine? Setting up GUI apps in a container is a bit of pain.

Thanks, makes perfect sense to me.
I'm on my phone, but I'll try just to add a couple of random notes:

• There's no need to pass the full /dev to the docker container you can add: -v /dev/input:/dev/input:rw and --device /dev/uinput and that should be enough
• As for running Sunshine in Docker I'm the main mantainer of Games on Whales https://github.com/games-on-whales/gow where we build a little image on top of Sunshine (coincidentally it's mainly just to setup additional user/group access) and a bunch of others so that you can "easily" run this in Docker.

Isn't the input devices group and mode redundant then and can be left unchanged?

Or do you want to keep it for mentioned cases with users created in containers where it may still be needed?

Yes, the original intention was to keep group and mode for special cases, such as users created in Docker containers. Regular Linux users don't need group/mode configuration. TAG+="uaccess" already handles that.

But as discussed above, Sunshine container also doesn't seem to need additional group/mode configuration because it passes UID of host user to container. So GROUP="input", MODE="0660" seem redundant in this particular case as well.

Should I remove group/mode from udev rule and fully rely on TAG+="uaccess"? This is basically exactly what Steam did:

https://github.com/ValveSoftware/steam-devices/blob/master/60-steam-input.rules#L5

Should I remove group/mode from udev rule and fully rely on TAG+="uaccess"? This is basically exactly what Steam did:

Seems reasonable to not override distro and possibly admin decisions about these UNIX permissions if Sunshine is not commonly make us of them anymore. However, let Sunshine maintainers comment on this first, as I would understand the argument to leave it in place for another testing/feedback iteration.

Are there any negative effects leaving GROUP="input", MODE="0660" there?

Not necessarily. But distributors and admins will be thankful when the changes to the system are limited to what is really needed.

I guess let's remove it then and we can put it back if we find issues.

Done. I can think of only one negative effect. If a distro doesn't provide input group, udev might complain about it in system logs. Popular distros seem to have input group but it's better not to rely on it.