Skip to content

Conversation

@Jan200101
Copy link
Contributor

Any rule with the GROUP= setting with a non-system group gets ignored since systemd 258, uaccess handle handles access so its redundant.

For uaccess the udev developers recommend applying it on add and change actions but not on remove, adapted the rule to follow this.

Tested on Fedora 43

Any rule with the GROUP= setting with a non-system group gets ignored
since systemd 258, uaccess handle handles access so its redundant.

For uaccess the udev developers recommend applying it on add and change
actions but not on remove, adapted the rule to follow this.
@lurch
Copy link
Contributor

lurch commented Nov 2, 2025

I believe that this was written primarily to run on Raspberry Pi OS, where plugdev is a system group...

@Jan200101
Copy link
Contributor Author

I should have specified, with "system group" I was referring to what systemd-userdb describes as a system group which differ from regular groups.

While Raspberry Pi OS doesn't have the version of udev that depends on userdb and at least Ubuntu ship with configurations that makes plugdev a proper system group this is not a trivial setup to replicate on other distros where the rule would still be useful.

The rule already applies uaccess, which provides user access regardless of group, so there is no real point in assigning it to the plugdev group or explicitly setting the mode, which udev will manage on its own.

@lurch
Copy link
Contributor

lurch commented Nov 3, 2025

I know nothing about udev myself (so I hope that @will-v-pi will forgive me for interfering 😉 ), but a quick search finds https://wiki.archlinux.org/title/Udev#Allowing_regular_users_to_use_devices which suggests that the MODE= is still needed?

@Jan200101
Copy link
Contributor Author

Jan200101 commented Nov 3, 2025

Unsure about MODE= projects like flashrom or libsigrok don't use it at all and work perfectly fine and libftdi uses MODE=664.

The default permissions for a Pico on my system seems to be 664, maybe there is a benefit to preventing everyone from reading from the usb device?

@will-v-pi
Copy link
Contributor

@Jan200101 Is your issue that the file doesn’t work for you, or is it just that you think ideally it should be changed?

systemd v258 was only released a few months ago, so most OSes (RPiOS bookworm and trixie for example) will not be running it, and users may still be relying on the group setting.

@Jan200101
Copy link
Contributor Author

Both, I use Fedora so I got systemd v258 fairly quickly and the chance to udev stopped the rule from working without further modification to my system.

The rule changes I propose should work universally and have been tested against Raspberry Pi OS Bookworm and Fedora 43.

@will-v-pi
Copy link
Contributor

Both, I use Fedora so I got systemd v258 fairly quickly and the chance to udev stopped the rule from working without further modification to my system.

Which part of this PR is required to get it working correctly for you?

From reading the systemd 258 release notes I can't see why keeping the GROUP= would cause issues, as they should just be ignored. The ACTION!="remove" bit could be necessary though.

@Jan200101
Copy link
Contributor Author

Which part of this PR is required to get it working correctly for you?

From reading the systemd 258 release notes I can't see why keeping the GROUP= would cause issues

On distros without plugdev as a default group (anything not Debian based, though they also consider removing it) the user will need to add it themselves otherwise they run into
/etc/udev/rules.d/60-picotool.rules:4 Unknown group 'plugdev', ignoring.
which means uaccess does not get applied.

Lots of people (based on public recomendations) create a plugdev group using sudo groupadd plugdev to work around this and now udev is no longer able to assign to a non system group
/etc/udev/rules.d/60-picotool.rules:4 Group 'plugdev' is not a system group, ignoring.

One would have to either modify the group into becoming a system group or delete and recreate it to get this setup working.

By not depending on a specific group and simply making use of the uaccess mechanism the rule becomes distro agnostic* and will even continue to work once (if) debian deprecates the group.

* did not test with eudev but the rule should work on any up to date distro since 2014

as they should just be ignored. The ACTION!="remove" bit could be necessary though.

I see no harm in removing that, upstream suggests keeping it to only apply the rule when a device is added or changed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants