Change udev rules back to MODE="0664" instead of uaccess.

[theonlymb]

When you e.g. have a service that flashes your modules it might run as a dedicated user, which is unable to login. In this case uaccess does not work.

BTW, it might be useful to also add GROUP="plugdev" or something similar to the udev rules.
Also, I stripped my udev rules down to some leaner version relying on vendor-id.

e.g.:

SUBSYSTEM=="usb", ATTRS{idVendor}=="1fc9", MODE="0664", GROUP="plugdev"
SUBSYSTEM=="usb", ATTRS{idVendor}=="15a2", MODE="0664", GROUP="plugdev"
SUBSYSTEM=="usb", ATTRS{idVendor}=="0525", MODE="0664", GROUP="plugdev"
SUBSYSTEM=="usb", ATTRS{idVendor}=="3016", MODE="0664", GROUP="plugdev"
SUBSYSTEM=="usb", ATTRS{idVendor}=="066f", MODE="0664", GROUP="plugdev"
SUBSYSTEM=="usb", ATTRS{idVendor}=="18d1", MODE="0664", GROUP="plugdev"
SUBSYSTEM=="usb", ATTRS{idVendor}=="3016", MODE="0664", GROUP="plugdev"
SUBSYSTEM=="usb", ATTRS{idVendor}=="0483", MODE="0664", GROUP="plugdev"

[nxpfrankli]

@agx Do you have any concern about this change, which always revert your commit?

[agx]

This looks wrong to me as it breaks simple flashing for logged in in users and doesn't help as the rule still fails to set a group.

If you want group writablility then it should:

• check if group plugdev exists
• if group plugev exsist: add a rule that:
  • sets uaccess
  • sets group to plugdev
  • sets mode to 0644
• if group plugdev doesn't exist
  • just set uaccess

This wouldn't break the existing setup and would also make it simple for script use by just adding the flashing user to the group (e.g. plugdev on Debian).

[theonlymb]

So something like this?

# Check if group plugdev exists
ACTION=="add", SUBSYSTEM=="usb", RUN+="/bin/sh -c 'if getent group plugdev >/dev/null; then GOTO=\"group_writability\"; else GOTO=\"no_group_writability\"; fi'"

# Rule for devices with group writability
LABEL="group_writability"
SUBSYSTEM=="usb", ATTRS{idVendor}=="1fc9", GROUP="plugdev", MODE="0664", TAG+="uaccess"
SUBSYSTEM=="usb", ATTRS{idVendor}=="15a2", GROUP="plugdev", MODE="0664", TAG+="uaccess"
SUBSYSTEM=="usb", ATTRS{idVendor}=="0525", GROUP="plugdev", MODE="0664", TAG+="uaccess"
SUBSYSTEM=="usb", ATTRS{idVendor}=="3016", GROUP="plugdev", MODE="0664", TAG+="uaccess"
SUBSYSTEM=="usb", ATTRS{idVendor}=="066f", GROUP="plugdev", MODE="0664", TAG+="uaccess"
SUBSYSTEM=="usb", ATTRS{idVendor}=="18d1", GROUP="plugdev", MODE="0664", TAG+="uaccess"
SUBSYSTEM=="usb", ATTRS{idVendor}=="3016", GROUP="plugdev", MODE="0664", TAG+="uaccess"
SUBSYSTEM=="usb", ATTRS{idVendor}=="0483", GROUP="plugdev", MODE="0664", TAG+="uaccess"

# Rule for devices without group writability
LABEL="no_group_writability"
SUBSYSTEM=="usb", ATTRS{idVendor}=="1fc9", TAG+="uaccess"
SUBSYSTEM=="usb", ATTRS{idVendor}=="15a2", TAG+="uaccess"
SUBSYSTEM=="usb", ATTRS{idVendor}=="0525", TAG+="uaccess"
SUBSYSTEM=="usb", ATTRS{idVendor}=="3016", TAG+="uaccess"
SUBSYSTEM=="usb", ATTRS{idVendor}=="066f", TAG+="uaccess"
SUBSYSTEM=="usb", ATTRS{idVendor}=="18d1", TAG+="uaccess"
SUBSYSTEM=="usb", ATTRS{idVendor}=="3016", TAG+="uaccess"
SUBSYSTEM=="usb", ATTRS{idVendor}=="0483", TAG+="uaccess"

[oliverwendt]

Cleaned up the doubles and sorted by idVendor. Checked the group_writability but don't have a non Debian based system for more checks.

# Check if group plugdev exists
ACTION=="add", SUBSYSTEM=="usb", RUN+="/bin/sh -c 'if getent group plugdev >/dev/null; then GOTO=\"group_writability\"; else GOTO=\"no_group_writability\"; fi'"

# Rule for devices with group writability
LABEL="group_writability"
SUBSYSTEM=="usb", ATTRS{idVendor}=="0483", GROUP="plugdev", MODE="0664", TAG+="uaccess"
SUBSYSTEM=="usb", ATTRS{idVendor}=="0525", GROUP="plugdev", MODE="0664", TAG+="uaccess"
SUBSYSTEM=="usb", ATTRS{idVendor}=="066f", GROUP="plugdev", MODE="0664", TAG+="uaccess"
SUBSYSTEM=="usb", ATTRS{idVendor}=="15a2", GROUP="plugdev", MODE="0664", TAG+="uaccess"
SUBSYSTEM=="usb", ATTRS{idVendor}=="18d1", GROUP="plugdev", MODE="0664", TAG+="uaccess"
SUBSYSTEM=="usb", ATTRS{idVendor}=="1fc9", GROUP="plugdev", MODE="0664", TAG+="uaccess"
SUBSYSTEM=="usb", ATTRS{idVendor}=="3016", GROUP="plugdev", MODE="0664", TAG+="uaccess"

# Rule for devices without group writability
LABEL="no_group_writability"
SUBSYSTEM=="usb", ATTRS{idVendor}=="0483", TAG+="uaccess"
SUBSYSTEM=="usb", ATTRS{idVendor}=="0525", TAG+="uaccess"
SUBSYSTEM=="usb", ATTRS{idVendor}=="066f", TAG+="uaccess"
SUBSYSTEM=="usb", ATTRS{idVendor}=="15a2", TAG+="uaccess"
SUBSYSTEM=="usb", ATTRS{idVendor}=="18d1", TAG+="uaccess"
SUBSYSTEM=="usb", ATTRS{idVendor}=="1fc9", TAG+="uaccess"
SUBSYSTEM=="usb", ATTRS{idVendor}=="3016", TAG+="uaccess"

[agx]

@oliverwendt @mb-karo I think that's pretty close. I'd just let mfgtools do the group lookup at rule installation time as getent in udev rules can take a very long time if you e.g. have LDAP lookups configured in nsswitch.conf (which likely isn't even functional when the udev rules are created). This would also allow to make the groupname configurable as e.g. command line option.

[oliverwendt]

@oliverwendt @mb-karo I think that's pretty close. I'd just let mfgtools do the group lookup at rule installation time as getent in udev rules can take a very long time if you e.g. have LDAP lookups configured in nsswitch.conf (which likely isn't even functional when the udev rules are created). This would also allow to make the groupname configurable as e.g. command line option.

Well did run the rules as a rule file in /etc/udev/rules.d having set:

udevadm control --log-priority=debug
journalctl -n 500 -f

and in an other instance

udevadm monitor

And I don't see any real lag in getent in my journaldctl log as given hereafter:
(Be aware that my rules file has some comments before # Check if group plugdev exists thus 74-uuu.rules:35 is ATTRS{idVendor}=="1fc9" in this example)

Dec 11 18:24:02 test-pc systemd-udevd[833457]: 1-1:1.0: /etc/udev/rules.d/74-uuu.rules:26 RUN '/bin/sh -c 'if getent group plugdev >/dev/null; then GOTO="group_writability"; else GOTO="no_group_writability"; fi''
Dec 11 18:24:02 test-pc systemd-udevd[833457]: 1-1:1.0: /etc/udev/rules.d/74-uuu.rules:35 GROUP 46
Dec 11 18:24:02 test-pc systemd-udevd[833457]: 1-1:1.0: /etc/udev/rules.d/74-uuu.rules:35 MODE 0664

EDIT:
Yes, I understand that with LDAP there might be lag, but AFAIK getent actually reads either a buffer, or the groups file itself, that should be essentially lag free. So the commands above should give someone with that setup some capability to test and check.

EDIT #2:
Clarification journaldctl log and rules output.

[agx]

Yes, I understand that with LDAP there might be lag, but AFAIK getent actually reads either a buffer, or the groups file itself, that should be essentially lag free. So the commands above should give someone with that setup some capability to test and check.

What getent really does depends on your nssswitch.conf. It might be lots of things. The udev manpage says for RUN:

Note that running programs that access the network or mount/unmount filesystems is not allowed inside of udev rules, due to the default sandbox that is enforced on systemd-udevd.service.

and there certainly can be network access with getent.

EDIT: I understand that it's fast on your system and it's certainly also fast over here but I've seen plenty of setups where that isn't the case and getent causes trouble during boot when udev rules are applied. This can e.g. lead to slow booting systems when you have a device attached but not when it's disconnected. Troublesome to debug.