udev rules not working

ocket8888 · 2018-10-31 13:15:02

I'm not sure if this belongs on System Administration or here - please move it if it is the former - but I'm having some issues with udev rules. These udev rules, specifically:

# Make uinput load
SUBSYSTEM=="input", RUN+="/sbin/modprobe uinput"

# Set permissions for uinput devices
KERNEL=="event*|uinput", GROUP="plugdev", MODE="0660"

# Logitech G510 and G510s
SUBSYSTEM=="usb", ACTION=="add", ATTRS{idVendor}=="046d", ATTRS{idProduct}=="c22d", MODE="0660", GROUP="plugdev"
SUBSYSTEM=="usb", ACTION=="add", ATTRS{idVendor}=="046d", ATTRS{idProduct}=="c22e", MODE="0660", GROUP="plugdev"

These are intended to allow access to my Logitech G510s keyboard. However, I've tried placing these rules at /lib/udev/rules.d/99-g510s.rules`, `/etc/udev/rules.d/99-g510s.rules` and `/usr/lib/udev/rules.d/99-g510s` as per wiki suggestions. Between each attempt I did a full system reboot (I had previously tried `sudo udevadm --reload && sudo udevadm trigger` to no avail), but still get "Permission Denied" when libusb tries to access the device. My user is a member of the "plugdev" group, and I've confirmed that write access is allowed when I run as root via `sudo`and as far as I can tell there's nothing wrong with the syntax here. In fact, it works fine on Debian when placed at `/lib/udev/rules.d/99-g510s.rules`.

What's wrong with my udev rules?

seth · 2018-10-31 18:01:24

lsusb
groups
stat <device path>

Also what exactly is "libusb tries to access the device" (process, eg ensure the binary has no sgid bit or similar)

ocket8888 · 2018-10-31 18:20:00

This is just a quick reply - not actually at the computer - but for right now what I can tell you is that `lsusb` will show the device exists on the bus, and that my user is absolutely a member of the 'plugdev' group.
stat pending my return home

"libusb tries to access the device" means that the binary using it finds the devices and attempts to write to it but is denied permissions. Once again, can't check the sgid bit 'till I get home.

What might help in the meantime is the binary in question's source code: https://github.com/vividnightmare/g510s
also the place where I got the udev rules. I built and installed with

make
sudo make install

but like I mentioned, I did try moving the udev rules to see if that would help (it did not)

damjan · 2018-10-31 18:51:36

General suggestion: don't use plugdev or other groups, use the uaccess TAG (TAG+="uaccess")

Just so there's no confusion the proper place for the file is: /etc/udev/rules.d/50-logitech.rules (you can customize the "logitech" but leave the others as is).

now, what exact device node (in /dev/) do you try to access?

seth · 2018-10-31 22:13:41

About lsusb: I'm mostly after the vendor or rather product ID to ensure you're not matching devices you don't actually have.

ocket8888 · 2018-11-01 12:55:56

I did not remember to do anything with the device in `/dev/...`, unfortunately - was a bit busy yesterday and I rushed through.
What I can say is that the executable does NOT have the sgid bit set, and the relevant line from `lsusb` is this:

Bus 001 Device 002: ID 046d:c22d Logitech, Inc. G510 Gaming Keyboard

seth · 2018-11-01 12:58:26

The device node stats…

ocket8888 · 2018-11-01 21:38:23

I'm not totally sure if this is correct, but I believe my keyboard is at /dev/bus/usb/001/002 . I mean, I know it is, but I'm not totally sure that's how it's being accessed, but if I understand the source code it appears to be looking at each bus and then each device on each bus, which I'd guess means it's that one. Here's the stat output:

  File: /dev/bus/usb/001/002
  Size: 0        Blocks: 0        IO Block: 4096    character special file
Device: 6h/6d   Inode: 219      Links: 1   Device type: bd,1
Access: (0755/drwxr-xr-x)  Uid: (   0/   root)   Gid:  (   0/   root)
Access: 2018-11-01 09:17:55.780160898 -0600
Modify: 2018-11-01 09:17:55.780160898 -0600
Change: 2018-11-01 09:17:55.780160898 -0600
 Birth: -

seth · 2018-11-01 22:00:58

You can strace the libusb using process to check which files it tries to open.
That device is obviously not altered in group or permission, so either it's not the proper device, the rule is never executed (not loaded or does not apply) or the group is reversed later.

You could add some debug echo RUN+ and also try

udevadm trigger -v -t subsystems -c add -s usb -a "idVendor=046d"

Arch Linux

#1 2018-10-31 13:15:02

udev rules not working

#2 2018-10-31 18:01:24

Re: udev rules not working

#3 2018-10-31 18:20:00

Re: udev rules not working

#4 2018-10-31 18:51:36

Re: udev rules not working

#5 2018-10-31 22:13:41

Re: udev rules not working

#6 2018-11-01 12:55:56

Re: udev rules not working

#7 2018-11-01 12:58:26

Re: udev rules not working

#8 2018-11-01 21:38:23

Re: udev rules not working

#9 2018-11-01 22:00:58

Re: udev rules not working

Board footer