Udev regression / recommended way for udev rules?

Help
1

After a NixOS-update some time ago (24.11 to 25.05?), previously working udev rules to make the devices user-accessible:

SUBSYSTEM=="usb", ATTR{idVendor}=="....", ATTR{idProduct}=="....", TAG+="uaccess", RUN{builtin}+="uaccess"

failed to build with the error:

Unknown builtin command ‘uaccess’, ignoring.

Removing RUN{builtin}+="uaccess" made the device unaccessible for users.

So, is this a bug/regesseion, or what’s the recommended way to make devices user-accessible again?

2

AFAICT that bit doesn’t mean anything and you should remove it. The tag should be sufficient.

I guess NixOS at some point introduced a check step that makes sure your udev rules are actually correct; your rule has likely been partially wrong since you’ve written it, but as the message says the superfluous action is ignored in practice.

The udev check still fails with exit code 1 so NixOS refuses to switch to a configuration with a udev rule that is partially broken, even if that brokenness doesn’t in practice cause unexpected behavior - you might, after all, have intended for that bit to mean something.

That doesn’t explain why the tag isn’t working, of course. Given that you have apparently not used the rule since 24.11, consider double checking the attribute checks are still correct.

3

Looks like the feature was indeed added in 25.05: https://github.com/NixOS/nixpkgs/pull/406284

4

Unfortunately, it’s not. With only TAG+="uaccess", the device is not accessible for the user.
Before, with RUN{builtin}+="uaccess" it was accessible.

The idVendor and idProduct ids in ATTR are still correct.

Maybe it’s because services.udev.extraRules is put into 99-local.rules, but uaccess only works for < 73-…. So, how can I add rules, which are executed before 73-…?

5

So, there was actually a change in how systemd handles uaccess, though there’s still some cause for confusion here… The short version is that systemd moved some uaccess handling out of logind so it’s all in udev now, and this has some consequences. Previously all you had to do was add the tag, and logind would make sure it applied correctly. But now that udev handles it on its own, and only in 73-seat-late.rules, that means rules with higher numbers (like the 99-local.rules that services.udev.extraRules go into) apply too late and have no effect; see: https://github.com/systemd/systemd/issues/39206. Technically this was always an issue; udev has always applied RUN{builtin}+="uaccess" in 73-seat-late.rules, meaning adding the tag in 99-local.rules has always resulted in the device not having the ACLs until logind took care of it, which was always a little wrong. But now that wrongness propagates more deeply, since logind isn’t handling it at all anymore.

What I don’t understand is why you adding RUN{builtin}+="uaccess" yourself didn’t work. I don’t see a reason other rules shouldn’t be able to use this builtin. I mean, that was never the way it was intended for you to do things, but I don’t see why it wouldn’t work.

6

So, we would need some e.g. services.udev.rules70, which are executed before 73-*?

7

Well, you can always do

services.udev.packages = [
  (writeTextFile {
    name = "70-my-foo.rules";
    destination = "/etc/udev/rules.d/70-my-foo.rules";
    text = ''
      SUBSYSTEM=="usb", ATTR{idVendor}=="....", ATTR{idProduct}=="....", TAG+="uaccess"
    '';
    checkPhase = ''
      ${config.systemd.package}/bin/udevadm verify --resolve-names=late $out/etc/udev/rules.d/70-my-foo.rules
    '';
  })
];

But yea, maybe another nixos option might be worthwhile.

Still, I’m confused about the builtin being unavailable to you…

2 Likes
8

I think that uaccess never worked in extraRules or at least it’s not something new. I tripped on this same issue a couple years ago: https://github.com/NixOS/nixpkgs/issues/210856.

9

Hope I’m not muddying the waters if my issue is unrelated, but after upgrading to 25.11 I enabled the updated services.ddccontrol module, which includes hardware.i2c.enable, which has a uaccess rule in /etc/udev/rules.d/70-i2c.rules, which should come before 73-*.

But it does not seem to work. I’m logged in locally with GNOME and ddcutil environment reports that I2C devices are not accessible from my user. Adding my user to the i2c group still works.

Based on previous commits in my config removing the i2c group addition, I think the uaccess rule did work at one point?

10

I don’t have 25.11 on any machine with i2c, yet. I’ll test this soon and report back.

11

I have the same issue as liam. After a recent update ddcutil environment reports I don’t have permission to access /dev/i2c-*.

WARNING: Current user (roconnor) does not have RW access to all /dev/i2c-* devices.
Checking for group i2c...
Group i2c exists
WARNING: Current user roconnor is NOT a member of group i2c

Looking for udev rules files that reference i2c:
Checking rules directory /lib/udev/rules.d:
grep: /lib/udev/rules.d/*rules: No such file or directory
Checking rules directory /run/udev/rules.d:
Checking rules directory /etc/udev/rules.d:
/etc/udev/rules.d/70-i2c.rules:# allow group i2c and users with a seat use of i2c devices
/etc/udev/rules.d/70-i2c.rules:ACTION=="add", KERNEL=="i2c-[0-9]*", TAG+="uaccess", GROUP="i2c", MODE="660"