udev: use ENV{ID_DEBUG_APPLIANCE} instead of GROUP and direct uaccess

[CoelacanthusHex]

GROUP can't be used for

• It's not concrete. All users in plugdev groups can use all devices in plugdev group, whatever it's phone, camera, microphone or debugprobe.
• It's not flexible. The user list need be maintained manually. And if update, user need to re-login to take effect.
• It doesn't work on modern Linux distros. On modern Linux world, only Debian and its derived distros have plugdev group by default. Arch, Fedora and Gentoo have no plugdev group by default at all. And systemd have a behavior: if the group declared in GROUP="" doesn't exist (since udev v174 released 2011 and systemd v183 released in 2012) or isn't system group (since v258 released in 2025), it will ignore the whole udev rule line (not only the chown operation).So our rule won't work on most modern Linux.

uaccess mechanism has been introduced since systemd v30, which is released in 2011 (systemd sync version number with udev since v183 so there is a jump from v44 to v183 in 2012), so we can assume modern Linux with systemd always has this feature.

Direct uaccess rule shouldn't be used because according to the post of systemd developer1, the generic device class should be used instead.

Although systemd has ID_DEBUG_APPLIANCE generic device class, we can't use it directly because it was introduced in v258. So I used a trick: add a our own rule to check ENV{ID_DEBUG_APPLIANCE}=="on_chip_debugger". So if systemd has ID_DEBUG_APPLIANCE, it do a reduntant thing, but since the operation is same, it's idempotent so it's safe; if systemd has no ID_DEBUG_APPLIANCE, this rule will set it to uaccess and doesn't affect other rules.

The hint of probe-rs main program also need to be updated, to fix the issue mentioned in 2.

[nathansamson]

Isn't this a new systemd 258 thing? https://lists.freedesktop.org/archives/systemd-devel/2025-September/051670.html

So it would work an most distro's currently out in the world? (In a years time this would be different).

[CoelacanthusHex]

Isn't this a new systemd 258 thing? lists.freedesktop.org/archives/systemd-devel/2025-September/051670.html

So it would work an most distro's currently out in the world? (In a years time this would be different).

No. I updated the description. uaccess feature added since systemd v30, so we can we can safely assume modern Linux with systemd always has this feature. v258 just make our old mechanism doesn't take effect when plugdev is not system group. Before v258, it doesn't take effect if the plugdev group doesn't exist (the situation in most Linux distro.)

[kevinmehall]

While uaccess is widely supported, the ENV{ID_DEBUG_APPLIANCE}=="?*", TAG+="uaccess" default rule to set it based on ID_DEBUG_APPLIANCE appears to be new in 258. So this seems like the right way to go in the future, but it's not backwards-compatible.

One drawback of a uaccess-based approach users should be aware of is that the ACL is only added for users logged in locally, and not over SSH. Using ID_DEBUG_APPLIANCE does make it easy for a user to add their own group for this case, though.

[CoelacanthusHex]

While uaccess is widely supported, the ENV{ID_DEBUG_APPLIANCE}=="?*", TAG+="uaccess" default rule to set it based on ID_DEBUG_APPLIANCE appears to be new in 258. So this seems like the right way to go in the future, but it's not backwards-compatible.

Yeah, bad news. I will update.

One drawback of a uaccess-based approach users should be aware of is that the ACL is only added for users logged in locally, and not over SSH. Using ID_DEBUG_APPLIANCE does make it easy for a user to add their own group for this case, though.

Maybe we can keep using ID_DEBUG_APPLIANCE, but copy ENV{ID_DEBUG_APPLIANCE}=="?*", TAG+="uaccess" into our rule but commented, and inform users to make modifications in documents.

[CoelacanthusHex]

While uaccess is widely supported, the ENV{ID_DEBUG_APPLIANCE}=="?*", TAG+="uaccess" default rule to set it based on ID_DEBUG_APPLIANCE appears to be new in 258. So this seems like the right way to go in the future, but it's not backwards-compatible.

One drawback of a uaccess-based approach users should be aware of is that the ACL is only added for users logged in locally, and not over SSH. Using ID_DEBUG_APPLIANCE does make it easy for a user to add their own group for this case, though.

I use a ENV{ID_DEBUG_APPLIANCE}=="on_chip_debugger" trick to resolve it, see updated PR description for details.