Skip to content

Bogus Udev rule because of deprecated GROUP="plugdev"

Description:

In our udev rule, currently, the rule is like this:

ATTRS{idVendor}=="0483", ATTRS{idProduct}=="3744", MODE="660", GROUP="plugdev", TAG+="uaccess"

It tries to chmod 600 and chown :plugdev, and then add access permission for the active user session via uaccess's ACL. Look great, right? No! In systemd behavior, if the group mentioned in the GROUP rule doesn't exist, it will ignore the whole line rule. Since plugdev is not a system group in Arch Linux, any chown or uaccess operations will not work.

Before systemd v258, many users created the plugdev group by themselves to work around this issue. But since systemd v258, if the group is not a system group, it will ignore the whole line rule as well.1

That's all because this kind of udev rule is totally wrong: plugdev is a deprecated mechanism, it's not concrete, safe, and flexible, and superseded by uaccess around 2011 or 2012:

  • The plugdev system group was introduced in ancient days (before uaccess) to manage device access by Debian.
    • It's not concrete. All users in plugdev groups can use all devices in the plugdev group, regardless of whether it's a phone, camera, microphone, or debug probe.
    • It's not safe because of the previous one. Imagine an SSH-logined user can access your camera or microphone.
    • It's not flexible. The user list needs to be maintained manually. And if any update, the user needs to re-login to take effect.
  • systemd v30 (released in 2011-07-14) introduced the uaccess mechanism234, and then udev v174 (released in 2011-10-20) and systemd v183 (released in 2012-05-25) added the ignore behavior5. (systemd sync version number with udev since v183, so there is a jump from v44 to v183 in 2012)
  • Fedora removed the plugdev system group and uses the uaccess mechanism at least since Fedora 16 (released in 2011) (Maybe they never introduced plugdev, I'm not sure.). Some reports after their migration can be found in 67.
  • Arch Linux never introduced the plugdev system group (At least I have not found it in the filesystem package history).
  • Today, only Debian and its derived distros have the plugdev system group.

So I suggest:

  1. Make a plan to refresh all udev rules in our packages, use the uaccess mechanism, and remove all GROUP="plugdev" usage.
  2. Update our Packaging Guideline, tell the packagers that when they package some software that includes udev rules, they should use the uaccess mechanism, and remove all GROUP="plugdev" usage.
  3. Push the software upstream to migrate from plugdev to the uaccess mechanism.

Additional Information:

Actually, using TAG+="uaccess" is also not the best solution, according to the reply8 of Kay Sievers (the developers of udev and systemd), direct use of uaccess should be avoided; instead, software should use a generic device class, and then the systemd built-in rule will set uaccess for the generic device class. All generic device class systemd currently supported can be found in 9, for example, for probe-rs, we should use ENV{ID_DEBUG_APPLIANCE}="on_chip_debugger" or something similar.

  1. https://github.com/systemd/systemd/blob/608fc3fa2c4902d84fd925b328b730d3b2dbff50/NEWS#L64 ↩

  2. https://github.com/systemd/systemd/commit/5eda94dda25bccda928c4b33c790dbe748573a22 ↩

  3. https://github.com/systemd/systemd/commit/3f49d45a45c6c585098590174c3245d2d9bdde0a ↩

  4. https://github.com/systemd/systemd/commit/0b191e603cc31ef0aff435fe20d49c7df39dfb8c ↩

  5. https://github.com/systemd/systemd/commit/3a020a85da768808a03f1574b001d1d06d55ae07 ↩

  6. https://bugzilla.redhat.com/show_bug.cgi?id=815093 ↩

  7. https://bugzilla.redhat.com/show_bug.cgi?id=859244 ↩

  8. http://lists.freedesktop.org/archives/systemd-devel/2012-March/004792.html ↩

  9. https://github.com/systemd/systemd/blob/main/rules.d/70-uaccess.rules.in ↩

Edited by Celeste Liu
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information