protonscr

Rename /lib/udev/rules.d/99-steam-controller-perms.rules

steamclosed Steam controllerDistro Family: Gentoo
ValveSoftware/steam-for-linux#5169 · opened 2017-09-17 by devurandom · updated 2019-08-17 · 8 comments · github
Ddevurandom 2017-09-17 github

Your system information

  • Steam client version (build number or date): 1.0.0.54
  • Distribution (e.g. Ubuntu): Gentoo Linux
  • Opted into Steam client beta?: [Yes/No] No
  • Have you checked for system updates?: [Yes/No] Yes

Please describe your issue in as much detail as possible:

It appears that the uaccess TAG is interpreted in /lib/udev/rules.d/73-seat-late.rules (belonging to systemd), which comes before /lib/udev/rules.d/99-steam-controller-perms.rules (belonging to Steam) in the list. Because of this, the uaccess TAG of the Valve devices is apparently not being acted upon and the /dev/uinput device node does not get an ACL set for the currently logged in user. All other files that set TAG+="uaccess" on my system also become before 73, usually at 60 or 70 in the list.

Steps for reproducing this issue:

  1. Install Steam
  2. Plug in a Steam Controller
  3. Observe that /dev/uinput has no ACL set

Proposed fix

Renaming the file from 99-steam-controller-perms.rules to 60-steam-controller-perms.rules solves the issue of the /dev/uinput file being inaccessible to the currently logged in user.

In addition, I also replaced all MODE="0666" actions with TAG+="uaccess", TAG+="udev-acl" to limit the users having access to these devices to the one sitting in front of the screen:

 Valve USB devices
SUBSYSTEM=="usb", ATTRS{idVendor}=="28de", TAG+="uaccess", TAG+="udev-acl"

# Steam Controller udev write access
KERNEL=="uinput", SUBSYSTEM=="misc", TAG+="uaccess", TAG+="udev-acl"

# Valve HID devices over USB hidraw
KERNEL=="hidraw*", ATTRS{idVendor}=="28de", TAG+="uaccess", TAG+="udev-acl"

# Valve HID devices over bluetooth hidraw
KERNEL=="hidraw*", KERNELS=="*28DE:*", TAG+="uaccess", TAG+="udev-acl"

# DualShock 4 over USB hidraw
KERNEL=="hidraw*", ATTRS{idVendor}=="054c", ATTRS{idProduct}=="05c4", TAG+="uaccess", TAG+="udev-acl"

# DualShock 4 wireless adapter over USB hidraw
KERNEL=="hidraw*", ATTRS{idVendor}=="054c", ATTRS{idProduct}=="0ba0", TAG+="uaccess", TAG+="udev-acl"

# DualShock 4 Slim over USB hidraw
KERNEL=="hidraw*", ATTRS{idVendor}=="054c", ATTRS{idProduct}=="09cc", TAG+="uaccess", TAG+="udev-acl"

# DualShock 4 over bluetooth hidraw
KERNEL=="hidraw*", KERNELS=="*054C:05C4*", TAG+="uaccess", TAG+="udev-acl"

# DualShock 4 Slim over bluetooth hidraw
KERNEL=="hidraw*", KERNELS=="*054C:09CC*", TAG+="uaccess", TAG+="udev-acl"

See-Also: anyc/steam-overlay#200

Bbergmannf 2018-06-13 github

It seems that anything named after 73-seat-late.rules not working with uaccess is expected behavior from systemd as well: https://github.com/systemd/systemd/issues/4288

PPlagman 2018-06-13 github

Thanks for the pointers; what is the purpose of the 'udev-acl' tag? We use MODE=0666 for wide compatibility with older distributions, but maybe it's time to switch across the board.

It would be nice to turn https://github.com/ValveSoftware/steam-devices into a generic list of VID/PIDs with metadata on what sort of access Steam and other components need from them, and have a generator script to produce rules that work for a desired distribution. Then we could automatically update our package to pick up updates from it.

Bbenley 2018-06-29 github

udev-acl is for compatibility with older distributions too; it is something handled by ConsoleKit.

I'm not sure exactly when systemd gained the uaccess mechanism, but it has been around (and udev-acl deprecated) since at least 2012 according to this blog post: https://enotty.pipebreaker.pl/2012/05/23/linux-automatic-user-acl-management/

I doubt any major distributions still need the udev-acl method, but it's also harmless to keep both TAG+="uaccess" and TAG+="udev-acl" around, as far as I know.

PPlagman 2018-08-28 github

Hi all,

I just released version .56 of our package, which includes a fix for this and tidies up the filenames a bit:

pgriffais@pgriffais:~$ dpkg -L steam-launcher | grep 60-
/lib/udev/rules.d/60-steam-vr.rules
/lib/udev/rules.d/60-steam-input.rules

Can you re-test on the latest package and confirm whether it's fixed for you?

Aakien-mga 2018-08-30 github

Thanks for the fix @Plagman, I can confirm that renaming to something below 73 was indeed necessary, at least on my distro Mageia where I package Steam. I had that change in my package since a year or two and it works fine (sorry for not writing an issue about it, I got the "60" value mostly by trial and error, I'm not really knowledgeable about udev rules).

Here's another change I have in my package compared to 1.0.0.56:

$ diff -aur SOURCES/60-steam-input.rules SOURCES/60-steam-input-mga.rules 
--- SOURCES/60-steam-input.rules        2018-08-30 11:36:44.750885160 +0200
+++ SOURCES/60-steam-input-mga.rules    2018-08-30 13:47:07.352110097 +0200
@@ -1,7 +1,7 @@
 # Valve USB devices
-SUBSYSTEM=="usb", ATTRS{idVendor}=="28de", MODE="0666"
+SUBSYSTEM=="usb", ATTRS{idVendor}=="28de", MODE="0660", TAG+="uaccess"
 # Steam Controller udev write access
-KERNEL=="uinput", SUBSYSTEM=="misc", TAG+="uaccess"
+KERNEL=="uinput", SUBSYSTEM=="misc", OPTIONS+="static_node=uinput", TAG+="uaccess"
 
 # Valve HID devices over USB hidraw
 KERNEL=="hidraw*", ATTRS{idVendor}=="28de", MODE="0666"

I don't remember exactly what was the rationale for the first change (MODE to 0660 instead of 0666 and TAG+="uaccess"), but probably to prevent access by other everyone.

The OPTIONS+="static_node=uinput" addition seems necessary for me to use my Steam Controller with https://github.com/kozec/sc-controller

AAlexandreBonneau 2018-09-07 github

@Plagman 10.0.0.56 solved my problem with the Steam controller not having the correct permissions for use from sc-controller.

Thanks!

Ssharkwouter 2019-08-17 github

@Plagman does this also affect the the rules found in the steamos-base-files package in SteamOS?

It contains the following files:

  • /usr/lib/udev/99-fanatec-wheel-perms.rules
  • /usr/lib/udev/99-logitech-wheel-perms.rules

I can't test this since I don't have these wheels, though.

Upstream links