udev rules on Arch(-ish) systems

[Manawyrm]

udev rules on Arch(-ish) systems

[whitequark]

Okay, I figured this mess out. It's all in #442.

[ewenmcneill]

Yes, I'd also suggest adding sudo udevadm control --reload to the documentation (AFAICT some systems will do it based on inotify of file writes, and some systems won't).

There's also sudo udevadm trigger (which can take options to match to a specific device, but I've not looked up the exact Glasgow match). The "trigger" will reapply the updated udev rules to an already plugged in device, as if it was plugged in again. It might be worth suggesting that rather than needing people to unplug/replug the device.

IIRC plugdev as a group is a Debian / Ubuntu thing. I'm not quickly finding it on some RHEL / CentOS systems I've checked either (and online references suggest it won't be on Fedora either). I'm not sure what other group name would be common across all Linux that would make sense here; dialout is a bit more common across Linux distros, but not really the right group (it's intended for serial TTYs). Possibly the sudo group which is somewhat common across distros? (For reference Debian System Groups.)

Ewen

[whitequark]

One of the issues here is that TAG+="uaccess", which is the mechanism that's supposed to replace static groups, doesn't work on my (Debian) system for unknown reasons and is undocumented, like is usual for systemd. Someone who isn't me is going to deal with that.

(Actually, looking at this description it would simply not work unless you relogin to your desktop, which is insane, and so I hope the description is wrong.)

I'm going to close this issue because I don't want to deal with broken and undocumented systemd stuff. Anyone who has a demonstrably working solution (which works across OSes and with/without systemd) is welcome to offer a PR updating the udev rules. If the current state of udev rules is unsatisfying (due to missing plugdev group) I offer MODE:="0666" though since the Glasgow hardware is FX2-based this can probably effectively give a determined attacker root (e.g. by making it re-enumerate as a keyboard and hijacking a sudo invocation or something like that) and it's probably not something that should be done on shared machines.

I've opened #442 to track the addition of udevadm command, which seems incontroversial and simple.

[whitequark]

Looking carefully at Debian's SystemGroups page it seems that our current use of the plugdev group is actually a misuse, since it's not a disk:

plugdev: Allows members to mount (only with the options nodev and nosuid, for security reasons) and umount removable devices through pmount.

What a mess.

[whitequark]

I made some progress in figuring out what went wrong with TAG+="uaccess": it looks like it also needs TAG+="udev-acl":

SUBSYSTEM=="usb", ATTRS{idVendor}=="20b7", ATTRS{idProduct}=="9db1", TAG+="uaccess", TAG+="udev-acl"

With this rules file, the device does get an ACL applied:

$ getfacl /dev/bus/usb/001/004
getfacl: Removing leading '/' from absolute path names
# file: dev/bus/usb/001/004
# owner: root
# group: plugdev
user::rw-
user:whitequark:rw-
group::rw-
mask::rw-
other::r--

but it's still not accessible:

$ glasgow list
Traceback (most recent call last):
  File "/home/whitequark/.local/bin/glasgow", line 8, in <module>
    sys.exit(main())
             ^^^^^^
  File "/home/whitequark/Projects/glasgow/software/glasgow/cli.py", line 919, in main
    exit(loop.run_until_complete(_main()))
         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.11/asyncio/base_events.py", line 653, in run_until_complete
    return future.result()
           ^^^^^^^^^^^^^^^
  File "/home/whitequark/Projects/glasgow/software/glasgow/cli.py", line 882, in _main
    for serial in sorted(GlasgowHardwareDevice.enumerate_serials()):
                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/whitequark/Projects/glasgow/software/glasgow/device/hardware.py", line 171, in enumerate_serials
    devices = cls._enumerate_devices(usb_context)
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/whitequark/Projects/glasgow/software/glasgow/device/hardware.py", line 92, in _enumerate_devices
    handle = device.open()
             ^^^^^^^^^^^^^
  File "/home/whitequark/.local/pipx/venvs/glasgow/lib/python3.11/site-packages/usb1/__init__.py", line 2055, in open
    mayRaiseUSBError(libusb1.libusb_open(self.device_p, byref(handle)))
  File "/home/whitequark/.local/pipx/venvs/glasgow/lib/python3.11/site-packages/usb1/__init__.py", line 127, in mayRaiseUSBError
    __raiseUSBError(value)
  File "/home/whitequark/.local/pipx/venvs/glasgow/lib/python3.11/site-packages/usb1/__init__.py", line 119, in raiseUSBError
    raise __STATUS_TO_EXCEPTION_DICT.get(value, __USBError)(value)
usb1.USBErrorAccess: LIBUSB_ERROR_ACCESS [-3]

Why? Who knows.

[whitequark]

usb1.USBErrorAccess: LIBUSB_ERROR_ACCESS [-3]

This error message is terrible, I've fixed it in #442. It now looks like:

$ glasgow list
E: g.device.hardware: missing permissions to open device 001/006

Then you can look at /dev/bus/usb/001/006 to see what's preventing you from accessing it. (We can't print the path because it differs between systems; this code is architecture-independent but devtmpfs usb nodes are Linux-specific obviously.)

[whitequark]

I made some progress in figuring out what went wrong with TAG+="uaccess": it looks like it also needs TAG+="udev-acl":

What's weird is that the Debian rules apply the plugdev group to the /dev/bus/usb device file whenever both of those tags are present, which seems to contradict Debian's own wiki on which devices should go to plugdev.

Scratch all of this; I was looking at the wrong device file, the tags have never worked in first place.