[PR #454] [CLOSED] fix(input): stop Wolf virtual controllers leaking into the host desktop #479

New issue

Closed

opened 2026-10-15 13:00:53 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-15 13:00:53 +00:00

Owner

📋 Pull Request Information

Original PR: https://github.com/games-on-whales/wolf/pull/454
Author: @JBailes
Created: 7/6/2026
Status: ❌ Closed

Base: stable ← Head: fix/controller-host-input-leak

📝 Commits (2)

16e1e0b fix(input): isolate Wolf virtual controllers from the host desktop
0c867e4 feat(scripts): add wolf-input-diag.sh controller passthrough diagnostic

📊 Changes

5 files changed (+483 additions, -19 deletions)

View changed files

📝 85-wolf.rules (+23 -10)
📝 docs/modules/user/pages/quickstart.adoc (+14 -9)
📝 docs/modules/user/pages/troubleshooting.adoc (+43 -0)
➕ scripts/README.adoc (+40 -0)
➕ scripts/wolf-input-diag.sh (+363 -0)

📄 Description

Problem

Wolf's virtual gamepads are created via uinput/uhid inside the Wolf container but appear as real devices in the host kernel. The udev rules that are supposed to keep them off the host's active seat don't do their job, so systemd-logind grants the logged-in desktop user a uaccess ACL and the streamed controller also drives the host desktop (e.g. the DualSense touchpad moves the host mouse pointer).

Fixes #451. Also matches the reports in games-on-whales/unraid-plugin#57.

Root cause

Three compounding defects in 85-wolf.rules (and the copy in the quickstart docs):

Stale device names. The rules match Wolf PS5 (virtual) pad and Wolf gamepad (virtual) motion sensors, but the pad is created as Wolf DualSense (virtual) pad (src/moonlight-server/control/input_handler.cpp:126), and the kernel's hid-playstation driver names its children … pad Touchpad and … pad Motion Sensors. None of those match, so the rules never fire for the DualSense.
No rule for the DualSense touchpad child device — so it kept moving the host cursor even after a user corrected the pad name.
The actual leak vector. The joypad rules set only MODE/GROUP, with no seat reassignment and no uaccess removal. A uaccess ACL overrides the group permissions, so a pad leaked to the host even when its name matched — which is why the leak reproduced across Xbox, DualSense and the Wolf UI.

Fix

Match every Wolf virtual device by its Wolf name prefix (glob) instead of hard-coded names — covers the gamepad, the DualSense Touchpad + Motion Sensors child devices, and the hidraw node, and won't go stale on a future rename.
Match both the device's own name (ATTR, for the uinput pads) and any ancestor's name (ATTRS, for the uhid DualSense children + hidraw).
Park the devices on the phantom seat9 and strip the uaccess ACL so no logged-in host user can read them.
Update the quickstart docs to match, and add a troubleshooting entry.

New diagnostic — `scripts/wolf-input-diag.sh`

Host-side, non-destructive tool to validate controller passthrough and isolation (it never grabs a device, so it can't steal input from a running game):

host — audits every Wolf … device on the host and flags any reachable by a non-root user or not covered by the rules (the leak in this issue).
discover / static — lists per-container input devices and fails if a node is shared across containers.
monitor / live — live checks that input reaches the container it should and no other.

It doubles as the acceptance test for the rules change.

Testing

Device names verified against source (input_handler.cpp) and the pinned inputtino dependency; rules and script are syntax-checked.

⚠️ Needs confirmation on hardware with a physical DualSense. I don't have a way to assert the exact logind/udev behaviour (whether seat9 + TAG-="uaccess" fully strips the ACL on the touchpad child device) without a real device. Reproduce and confirm with the bundled diagnostic:

sudo ./scripts/wolf-input-diag.sh host   # BEFORE: LEAK lines for the pad + touchpad
sudo cp 85-wolf.rules /etc/udev/rules.d/ && sudo udevadm control --reload-rules && sudo udevadm trigger
# reconnect the controller, then:
sudo ./scripts/wolf-input-diag.sh host   # AFTER: all root-only, rule-covered

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/games-on-whales/wolf/pull/454 **Author:** [@JBailes](https://github.com/JBailes) **Created:** 7/6/2026 **Status:** ❌ Closed **Base:** `stable` ← **Head:** `fix/controller-host-input-leak` --- ### 📝 Commits (2) - [`16e1e0b`](https://github.com/games-on-whales/wolf/commit/16e1e0b03f58fa69fe5bf13b7940fc04468264bd) fix(input): isolate Wolf virtual controllers from the host desktop - [`0c867e4`](https://github.com/games-on-whales/wolf/commit/0c867e4058156862aa138037d3c153445067b210) feat(scripts): add wolf-input-diag.sh controller passthrough diagnostic ### 📊 Changes **5 files changed** (+483 additions, -19 deletions) <details> <summary>View changed files</summary> 📝 `85-wolf.rules` (+23 -10) 📝 `docs/modules/user/pages/quickstart.adoc` (+14 -9) 📝 `docs/modules/user/pages/troubleshooting.adoc` (+43 -0) ➕ `scripts/README.adoc` (+40 -0) ➕ `scripts/wolf-input-diag.sh` (+363 -0) </details> ### 📄 Description ## Problem Wolf's virtual gamepads are created via `uinput`/`uhid` inside the Wolf container but appear as **real devices in the host kernel**. The udev rules that are supposed to keep them off the host's active seat don't do their job, so `systemd-logind` grants the logged-in desktop user a `uaccess` ACL and the streamed controller **also drives the host desktop** (e.g. the DualSense touchpad moves the host mouse pointer). Fixes #451. Also matches the reports in games-on-whales/unraid-plugin#57. ## Root cause Three compounding defects in `85-wolf.rules` (and the copy in the quickstart docs): 1. **Stale device names.** The rules match `Wolf PS5 (virtual) pad` and `Wolf gamepad (virtual) motion sensors`, but the pad is created as `Wolf DualSense (virtual) pad` (`src/moonlight-server/control/input_handler.cpp:126`), and the kernel's `hid-playstation` driver names its children `… pad Touchpad` and `… pad Motion Sensors`. None of those match, so the rules never fire for the DualSense. 2. **No rule for the DualSense touchpad** child device — so it kept moving the host cursor even after a user corrected the pad name. 3. **The actual leak vector.** The joypad rules set only `MODE`/`GROUP`, with no seat reassignment and no `uaccess` removal. A `uaccess` ACL overrides the group permissions, so a pad leaked to the host **even when its name matched** — which is why the leak reproduced across Xbox, DualSense and the Wolf UI. ## Fix - Match every Wolf virtual device by its **`Wolf ` name prefix (glob)** instead of hard-coded names — covers the gamepad, the DualSense `Touchpad` + `Motion Sensors` child devices, and the `hidraw` node, and won't go stale on a future rename. - Match both the device's own name (`ATTR`, for the uinput pads) and any ancestor's name (`ATTRS`, for the uhid DualSense children + hidraw). - Park the devices on the phantom **`seat9`** and **strip the `uaccess` ACL** so no logged-in host user can read them. - Update the quickstart docs to match, and add a troubleshooting entry. ## New diagnostic — `scripts/wolf-input-diag.sh` Host-side, non-destructive tool to validate controller passthrough and isolation (it never grabs a device, so it can't steal input from a running game): - `host` — audits every `Wolf …` device on the host and flags any reachable by a non-root user or not covered by the rules (the leak in this issue). - `discover` / `static` — lists per-container input devices and fails if a node is shared across containers. - `monitor` / `live` — live checks that input reaches the container it should and no other. It doubles as the acceptance test for the rules change. ## Testing - Device names verified against source (`input_handler.cpp`) and the pinned `inputtino` dependency; rules and script are syntax-checked. - ⚠️ **Needs confirmation on hardware with a physical DualSense.** I don't have a way to assert the exact `logind`/`udev` behaviour (whether `seat9` + `TAG-="uaccess"` fully strips the ACL on the touchpad child device) without a real device. Reproduce and confirm with the bundled diagnostic: ```bash sudo ./scripts/wolf-input-diag.sh host # BEFORE: LEAK lines for the pad + touchpad sudo cp 85-wolf.rules /etc/udev/rules.d/ && sudo udevadm control --reload-rules && sudo udevadm trigger # reconnect the controller, then: sudo ./scripts/wolf-input-diag.sh host # AFTER: all root-only, rule-covered ``` --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>

bsakaguchi

2026-10-15 13:00:53 +00:00