[Feature]: Docs: Recommend targeted mouse udev rule instead of adding user to 'input' group for Wayland click capture #1084

Search existing issues

• I have searched the existing issues

Problem Description

In the Linux installation and platform documentation (Mouse clicks on Wayland), OpenScreen notes that distinguishing mouse clicks from movement on Wayland requires reading /dev/input/event*, and suggests:

sudo usermod -aG input $USER

While the documentation already includes a very fair caution about this, adding a desktop user account to the input group presents a substantial security hazard:

1. Ambient Keylogger Authority: The input group applies to all /dev/input/event* devices, including physical and virtual keyboards.
2. Once added to input, every unprivileged process running under that user (web browsers, build tools, npm/pip/cargo packages, IDE extensions) gains permission to open raw keyboard event streams in the background and record every keystroke (passwords, tokens, SSH keys, private chats).

Proposed Solution

On systemd-based Linux distributions, a safer and cleaner alternative is to deploy a targeted udev rule with TAG+="uaccess":

KERNEL=="event*", SUBSYSTEM=="input", ENV{ID_INPUT_MOUSE}=="1", ENV{ID_INPUT_KEYBOARD}!="1", TAG+="uaccess"

(e.g. placed in /etc/udev/rules.d/70-openscreen-mouse.rules, or deployed declaratively in NixOS / distro packages).

How This Works

1. Dynamic Seat ACLs: When a mouse device is plugged in or detected, udev attaches TAG+="uaccess". systemd-logind automatically assigns dynamic read/write POSIX ACLs (setfacl) on that specific device node exclusively to the active desktop session user.
2. Hardware Keyboard Exclusion: Keyboards are strictly excluded (ENV{ID_INPUT_KEYBOARD}!="1"). Even if userspace is compromised, the kernel refuses to open keyboard character devices.
3. No Group Membership: The user never needs to join the input group, and there is no need to log out and log back in for changes to take effect.
4. No Privileged Binaries: Avoids needing SUID/SGID binaries on disk.

Threat Profile Comparison

Additional Context & References

We have documented and verified this approach in our own setups:

• Detailed conceptual analysis: https://wiki.enola.dev/computer/linux/security/evdev-click-telemetry-security
• NixOS packaging & configuration reference: https://nixfiles.vorburger.ch/reference/openscreen

@EtienneLescot — would a docs-only PR updating website/docs/installation.md to explain and recommend this udev approach be a welcome contribution?

@Renna42 as something could potentially include in a future updated nixpgks (IFF there is interest)