You are not logged in.
Hello,
a number of my custom udev rules set permissions with a custom group (with an ID > 1000), and they stopped working with systemd 258, with the following error:
Group 'xxx' is not a system group, ignoring.
.
It seems this is a new systemd policy. This is pretty annoying. I may kind of see the security rationale, although I find this a bit too restrictive for typical "workstation" use.
Is there a workaround?
Last edited by OpusOne (2025-09-20 17:48:25)
Offline
Ok, solved it by doing what was obvious: create a new system group for these devices. I still wanted to use a group-based approach. I know it can also be done using ACL and the 'uaccess' tag in udev rules, but that's something I didn't want to get into for now.
So, created a new system group with 'groupadd --system', added the corresponding users to this group and modified my udev rules accordingly.
Maybe this will be useful for some other people, not necessarily the solution (which is not hard to figure out), but just for figuring out what causes a sudden permission issue with some devices.
Although they may cause issues in practice only for "niche" cases, it might be worth a post in the "Latest News" on the Arch homepage, as systemd 258 introduces some incompatible changes:
https://lists.freedesktop.org/archives/ … 51670.html
Last edited by OpusOne (2025-09-20 17:49:21)
Offline
Ugh, this is awful. All my setup is broken because of this freaking change. And it's just because they introduced "clock" system group and it may conflict with existing non-system group :facepalm:
https://github.com/systemd/systemd/issues/39056
Last edited by dimich (2025-09-21 01:04:48)
Offline
just because they introduced "clock" system group and it may conflict with existing non-system group
"So, … we use the whack-a-bug development process, sometimes called address-my-personal-itch-directly-by-pulling-random-strings-and-ignoring-the-consequences"
Offline
That is odd. I thought the base rationale was to increase security to avoid potential privilege escalation through devices with a non-system group permission (although I don't personally have a concrete case in mind for which that could be), but if the base reason is just to fix an issue they themselves caused, ugh.
My use case (which I thihk is not that uncommon) was to provide users of a given non-system group permissions to a set of files and a set of devices. Through a single group. That was handy and I think, made sense.
Now if we have to create additional system groups for device permissions, that's not a huge deal, but that's mildly annoying (especially is when you weren't warned upfront of the change), and also, at some point, we might be running out of system GIDs, so that's not ultra-scalable.
I guess the ultimate, more durable solution would be to switch to ACL? But that's another layer of annoyance, and in any case, I don't really like this kind of breaking changes unless they are absolutely critical for security. And again, I though that was the main rationale here, but apparently, it's only a secondary one. If it was really a security concern, I guess that would have been addressed a long time ago already.
Offline
There's nothing special about system groups except that the occupy a range where usergroups cannot/will not be created w/ useradd/groupadd (unless you explicitly call for a system group)
The kicker here is that the trigger for the change is that they're fully aware that such collision might occur what must imply the awareness that this *will* break things and also the change doesn't really address what happens if you had/have a user group "clock" - because you're not getting a second (system) group w/ that name either. So the situation then will just be that you do have the relevant group, but udev kinda silently ignores that because reasons.
The alternative would be systemd actually just highhandedly replaces the present group what means *all* files (not only device nodes) previously linked to that group are now broken and on top of everything the device nodes are transient, ie either collision would only exist until the next reboot and relevant to the udevadm trigger hook, which: https://bbs.archlinux.org/viewtopic.php?id=308341
Offline
I guess the ultimate, more durable solution would be to switch to ACL?
What do you mean by "switch to ACL"? Technically any permissions can be set with RUN+=. However, such workaround is ugly, and I'm not sure about atomicity and possible race conditions. Udev has had facility to set node owner, group and mode bits for a long time, why break it? I don't even understand how this restriction to system user/group may solve name conflict issue.
Offline
Not sure if related, but I think it is. Having GROUP="plugdev" in your udev rules, even if there is no plugdev group on your system, also seems to break now. For example, the udev rules shipped by ST Microelectronics for their ST-LINK devices include both GROUP="plugdev" and TAG+="uaccess". This used to work fine. The group would just get ignored if it didn't exist, but now plugdev doesn't work unless I also remove the GROUP statement. GROUP="plugdev" is invalid in arch packages according to the wiki, but this still affects compatibility with 3rd-party software that includes both.
Offline
You probably want to record that in the upstream bug, https://github.com/systemd/systemd/issues/39056
Even if the group behavior is being insisted on it probably should™ not cause failure of the entire rule?
Offline
#8 might be related to https://github.com/systemd/systemd/issu … 3317986886
Offline