uaccess ACL not applied to /dev/uinput without OPTIONS+="static_node=uinput"

[smcv]

• Steam client version: 1482202200, steam 1.0.0.54-1, steam-devices 1.0.0.54-1
• Distribution (e.g. Ubuntu): Debian unstable
• Opted into Steam client beta?: no
• Have you checked for system updates?: yes

This is Debian bug https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=818905.

/dev/uinput does not receive non-trivial ACLs, and as a result Steam's Steam Controller support cannot synthesize gamepad input events for games that expect an X-Box-style controller (specifically, I'm testing with Shadow Tactics: Blades of the Shogun in Big Picture mode).

Expected:

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

where somebody is whichever user is logged in on the currently active virtual console.

Actual:

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

Suggested solution

A change to the udev rules seems to resolve the issue: replace Valve's current recommendation

KERNEL=="uinput", SUBSYSTEM=="misc", TAG+="uaccess"

with

KERNEL=="uinput", SUBSYSTEM=="misc", TAG+="uaccess", OPTIONS+="static_node=uinput"

[Plagman]

Hi Simon,

Which recommendation are you referring to? In this post it looks like we have that option specified:

http://steamcommunity.com/app/353370/discussions/0/490123197956024380/

Are you using our Steam package containing our udev rules file as-is, or a Debian variant of it?

[kisak-valve]

Hello @Plagman,

I'm seeing OPTIONS+="static_node=uinput" missing in http://repo.steampowered.com/steam/pool/steam/s/steam/steam-launcher_1.0.0.54_all.deb -> data.tar.gz -> ./lib/udev/rules.d/99-steam-controller-perms.rules which is getting cloned downstream to debian's variant of the packaging.

[smcv]

Are you using our Steam package containing our udev rules file as-is, or a Debian variant of it?

The 1.0.0.54-1 Debian package maintained by the Debian Games Team, which is apparently based on something that Valve releases. On the linked Debian bug 818905 the maintainer said

The udev rule currently shipped is Valve's, so if you think it needs
to be changed, please start a discussion with them

but did not elaborate on which Valve package or documentation it came from.

The version from the steamcommunity article

KERNEL=="uinput", MODE="0660", GROUP="pgriffais", OPTIONS+="static_node=uinput"

isn't suitable for distros, because distros can't know which group is right. I assume that's why you used uaccess instead in SteamOS?

However, the version with a GROUP is probably easier for manual instructions, because it works independently of whether the OS distribution is using ConsoleKit, systemd-logind or neither.

[smcv]

(Debian's steam and steam-devices packages, combined, are roughly the same as Valve's steam-launcher.)

[Plagman]

Correct, we used uaccess for our package but GROUP for the general recommendation because uaccess seemed like a distro-specific mechanism. We can change our package to include the static_node=uinput clause for sure, do you have details on when the current line would break exactly? Is it an upcoming Debian change?

[smcv]

we used uaccess for our package but GROUP for the general recommendation because uaccess seemed like a distro-specific mechanism

Sort of; it's specific to distros that use a vaguely recent systemd-logind. The Gentoo wiki also mentions TAG+="udev-acl", which was the equivalent for the now-obsolete ConsoleKit. Having both is harmless, although I don't think any practically relevant distro still uses ConsoleKit.

Sorry, I don't know whether there's a cutoff version of something (udev/systemd? Linux?) where the version without static_node=uinput stopped working. This might have to be something that distributions that package the Steam launcher test for themselves.

[smcv]

It turns out the reason this works on SteamOS (at least brewmaster) is a patch to the default device permissions rules in udev to add the static_node=uinput option, adding this rule:

# Let the Steam controller and Steam streaming emulate input devices
KERNEL=="uinput", MODE="0660", GROUP="steam", OPTIONS+="static_node=uinput"

So SteamOS is already relying on the equivalent of the change I proposed.

The udev in Ubuntu 12.04 (which AIUI is your baseline for supporting Steam on desktop Linux?) appears to mention static_node in other rules, so that version clearly already understands the syntax.

For context, the purpose of the static_node option is to get the /dev/uinput device node pre-created with the designated permissions, before the uinput kernel module has even been loaded. Normally, the permissions and owners configured with udev rules are only applied when the kernel module that owns the device is active. However, there is a chicken-and-egg problem for uinput: that module is normally only loaded on-demand when something opens /dev/uinput. So if Steam cannot open /dev/uinput, nothing is going to trigger the kernel module being loaded, so /dev/uinput will never get the permissions that would allow Steam to open it :-)

See udev(7) for more details of the static_node option.

[smcv]

Are you using our Steam package containing our udev rules file as-is, or a Debian variant of it?

The 1.0.0.54-1 Debian package maintained by the Debian Games Team, which is apparently based on something that Valve releases.

That package is in fact a slightly cut-down version of Valve's steam/1.0.0.54 source package (the one that targets precise). It omits the bundled libraries from the bootstrap tarball and depends on newer Debian versions of those libraries instead. The udev rules are identical to the ones in Valve's steam-launcher/1.0.0.54.

[at46]

It seems the Debian maintainer still waits for Valve to add OPTIONS+="static_node=uinput"

[smcv]

It seems the Debian maintainer still waits for Valve to add OPTIONS+="static_node=uinput"

Yes. I think the concern might be that the licensing for Valve's steam-launcher allows Debian to redistribute those files, but does not allow modification. (Or is "scripts and other documentary and graphical files" in clause 1B(ii) of the EULA intended to cover the udev rules?)

@Plagman, would Valve be willing to put some permissive license (like MIT/X11) on that rules file, or clarify that the udev rules are intended to be modifiable under §1B(ii) in the EULA, or otherwise give permission for distros that redistribute it to modify it to be more suitable for their udev/kernel?

[Pobega]

FWIW I'm seeing the same thing on Debian Sid.

I don't want to start a chain of +1s, but it would be nice to have this resolved upstream so that Debian (and other distros) can integrate it. I manually edited my file the way that @smcv suggested and it works as expected.

Alternatively the change to the license would be great too.

Apologies for the added noise.

[nyanloutre]

Is this issue still considered by Valve ?

[Pobega]

The configuration files were relicensed MIT here: https://github.com/ValveSoftware/steam-devices

This issue is (mostly) no longer valid as distros should be repackaging the udev rules for their own setup (eg systemd or no-systemd)

[nyanloutre]

Oh OK I didn't know it was under MIT, thanks for the link !

[devurandom]

I downloaded the launcher from https://steamcdn-a.akamaihd.net/client/installer/steam.deb and that appears to contain the correct udev rule. Thus I think this issue can be closed.

[nyanloutre]

Yes I can confirm it's working with latest version on NixOS

[kisak-valve]

Closing as fixed in Debian's 1.0.0.54-6 Steam package and ValveSoftware/steam-devices#2.