4 ms·

These rules exist ostensibly for security, right? I wonder what the right model is here for interactive end-user operating systems. Just trust apps to behave an

These rules exist ostensibly for security, right? I wonder what the right model is here for interactive end-user operating systems. Just trust apps to behave and give them access to your devices? That's more-or-less what udev hacks end up amounting to in my experience... Maybe the API applications see should just ask the OS for a device that matches some description, and then the OS pops open a picker for the user, kinda like a file dialog? Selection of a device to pass to an application counts as granting permission to use it.

fc417fc802 8mo ago
Devices are typically controlled per-user. So if you want to increase isolation you need to run as a different UID. It's definitely a sub-par model IMO but it seems to work well enough. > and then the OS pops open a picker for the user, kinda like a file dialog? How would that work when I'm in a container or at a tty with nothing more than a shell?
- idle_zealot 8mo ago
  > How would that work when I'm in a container or at a tty with nothing more than a shell? I only really am considering designing for graphical systems. If you're doing server work or devops configuration living in a udev rule file feels more reasonable.
robinsonb5 8mo ago
I don't have a problem with the concept of udev - I just find the details to be laden with papercuts. Needing different syntax depending on which subsystem is interacting with the device makes no sense from a user perspective. To cover all bases my udev rule seems to need to contain both SUBSYSTEM="hidraw", ATTRS{interface}=="CMSIS-DAP", MODE="0660", GROUP="plugdev" and SUBSYSTEM="usb", ATTR{idVendor}=="1d50", ATTRS{idProduct}=="602b", MODE="0660", GROUP="plugdev" I don't understand why the second rule isn't sufficient, and finding enough information online to even consider trying the first rule was extremely difficult.
- BobbyTables2 8mo ago
  I think the main problem is there are several layers of events for the subsystems and absolutely no documentation on how they work!
  - robinsonb5 8mo ago
    More to the point, no documentation on how they work this year.
hrmtst93837 8mo ago
[flagged]

fc417fc802 8mo ago

Devices are typically controlled per-user. So if you want to increase isolation you need to run as a different UID. It's definitely a sub-par model IMO but it seems to work well enough. > and then the OS pops open a picker for the user, kinda like a file dialog? How would that work when I'm in a container or at a tty with nothing more than a shell?

idle_zealot 8mo ago
> How would that work when I'm in a container or at a tty with nothing more than a shell? I only really am considering designing for graphical systems. If you're doing server work or devops configuration living in a udev rule file feels more reasonable.

robinsonb5 8mo ago

I don't have a problem with the concept of udev - I just find the details to be laden with papercuts. Needing different syntax depending on which subsystem is interacting with the device makes no sense from a user perspective. To cover all bases my udev rule seems to need to contain both SUBSYSTEM="hidraw", ATTRS{interface}=="CMSIS-DAP", MODE="0660", GROUP="plugdev" and SUBSYSTEM="usb", ATTR{idVendor}=="1d50", ATTRS{idProduct}=="602b", MODE="0660", GROUP="plugdev" I don't understand why the second rule isn't sufficient, and finding enough information online to even consider trying the first rule was extremely difficult.

BobbyTables2 8mo ago
I think the main problem is there are several layers of events for the subsystems and absolutely no documentation on how they work!
- robinsonb5 8mo ago
  More to the point, no documentation on how they work this year.

hrmtst93837 8mo ago

[flagged]