Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 668880 - sys-fs/eudev: 40-gentoo.rules overwrite GROUP settings for USB devices
Summary: sys-fs/eudev: 40-gentoo.rules overwrite GROUP settings for USB devices
Status: RESOLVED OBSOLETE
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal with 1 vote (vote)
Assignee: eudev team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-10-17 16:27 UTC by Pavel Khaymi
Modified: 2023-10-11 20:03 UTC (History)
3 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
Patch for 40-gentoo.rules so that it is run only on "add" event. (eudev-gentoo-rules.patch,494 bytes, patch)
2018-12-04 07:21 UTC, Jyrki Launonen
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Pavel Khaymi 2018-10-17 16:27:06 UTC
50-udev-default.rules, 41-libsane.rules and others have ACTION checks before manipulate USB GROUP attr like this:

ACTION!="add", GOTO="default_end"

but 40-gentoo.rules has NOT and attached USB printers gets wrong group settings

i guess the problem is in "bind" action from UDEV going last.

udevdam monitor -p

UDEV  [4713.562780] add      /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.2 (usb)
ACTION=add
BUSNUM=001
DEVNAME=/dev/bus/usb/001/005
DEVNUM=005
DEVPATH=/devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.2
DEVTYPE=usb_device
ID_BUS=usb
ID_MODEL=Kyocera_ECOSYS_M2540dn
ID_MODEL_ENC=Kyocera\x20ECOSYS\x20M2540dn
ID_MODEL_ID=06fd
ID_REVISION=0000
ID_SERIAL=Kyocera_Kyocera_ECOSYS_M2540dn_VCG8681830
ID_SERIAL_SHORT=VCG8681830
ID_USB_INTERFACES=:070102:070104:ffffff:
ID_VENDOR=Kyocera
ID_VENDOR_ENC=Kyocera
ID_VENDOR_FROM_DATABASE=Kyocera Corp.
ID_VENDOR_ID=0482
MAJOR=189
MINOR=4
PRODUCT=482/6fd/0
SEQNUM=2343
SUBSYSTEM=usb
SYSTEMD_WANTS=configure-printer@usb-001-005.service
TAGS=:systemd:
TYPE=0/0/0
USEC_INITIALIZED=13562560

UDEV  [4713.563780] add      /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.2/1-1.2:1.0 (usb)
ACTION=add
DEVPATH=/devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.2/1-1.2:1.0
DEVTYPE=usb_interface
ID_VENDOR_FROM_DATABASE=Kyocera Corp.
INTERFACE=7/1/2
MODALIAS=usb:v0482p06FDd0000dc00dsc00dp00ic07isc01ip02in00
PRODUCT=482/6fd/0
SEQNUM=2344
SUBSYSTEM=usb
TYPE=0/0/0
USEC_INITIALIZED=13563570

UDEV  [4713.563867] add      /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.2/1-1.2:1.1 (usb)
ACTION=add
DEVPATH=/devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.2/1-1.2:1.1
DEVTYPE=usb_interface
ID_VENDOR_FROM_DATABASE=Kyocera Corp.
INTERFACE=255/255/255
MODALIAS=usb:v0482p06FDd0000dc00dsc00dp00icFFiscFFipFFin01
PRODUCT=482/6fd/0
SEQNUM=2345
SUBSYSTEM=usb
TYPE=0/0/0
USEC_INITIALIZED=13563695

UDEV  [4713.564777] add      /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.2/1-1.2:1.2 (usb)
ACTION=add
DEVPATH=/devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.2/1-1.2:1.2
DEVTYPE=usb_interface
ID_VENDOR_FROM_DATABASE=Kyocera Corp.
INTERFACE=255/255/255
MODALIAS=usb:v0482p06FDd0000dc00dsc00dp00icFFiscFFipFFin02
PRODUCT=482/6fd/0
SEQNUM=2346
SUBSYSTEM=usb
TYPE=0/0/0
USEC_INITIALIZED=13564571

UDEV  [4713.565404] bind     /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.2 (usb)
ACTION=bind
BUSNUM=001
DEVNAME=/dev/bus/usb/001/005
DEVNUM=005
DEVPATH=/devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.2
DEVTYPE=usb_device
DRIVER=usb
ID_BUS=usb
ID_MODEL=Kyocera_ECOSYS_M2540dn
ID_MODEL_ENC=Kyocera\x20ECOSYS\x20M2540dn
ID_MODEL_ID=06fd
ID_REVISION=0000
ID_SERIAL=Kyocera_Kyocera_ECOSYS_M2540dn_VCG8681830
ID_SERIAL_SHORT=VCG8681830
ID_USB_INTERFACES=:070102:070104:ffffff:
ID_VENDOR=Kyocera
ID_VENDOR_ENC=Kyocera
ID_VENDOR_FROM_DATABASE=Kyocera Corp.
ID_VENDOR_ID=0482
MAJOR=189
MINOR=4
PRODUCT=482/6fd/0
SEQNUM=2347
SUBSYSTEM=usb
TYPE=0/0/0
USEC_INITIALIZED=13562560
Comment 1 Jyrki Launonen 2018-10-18 11:32:17 UTC
I felt adventurous and added two lines to the /lib/udev/rules.d/40-gentoo.rules file. At beginning

   ACTION!="add", GOTO="gentoo_end"

and at end

   LABEL="gentoo_end"

. This change seems to have fixed sys-power/nut not being not able to start upsdrv at all due wrong permissions. Sure, I have only one observation so far... And I don't know if anything has broken from this (other than the change going to be reverted at next update).
Comment 2 Pavel Khaymi 2018-10-18 12:54:41 UTC
i placed file with same modifications in /etc/udev/rules.d/40-gentoo.rules
it has higher priority and not to be overwritten on update
Comment 3 Anthony Basile gentoo-dev 2018-10-26 14:06:04 UTC
can you test eudev-3.2.7 and let me know what you find.  i just added it to the tree.  thanks.
Comment 4 Jyrki Launonen 2018-10-27 06:50:58 UTC
(In reply to Anthony Basile from comment #3)
> can you test eudev-3.2.7 and let me know what you find.  i just added it to
> the tree.  thanks.

3.2.7 doesn't seem to fix the original problem if the 40-gentoo.rules is not modified, at least on my case. I didn't reboot after update, only restarted the service and additionally forced reloading of rules with udevadm. Suddenly though, it seems that there is quite many events when the device is removed or re-plugged, but I haven't yet checked whether that was the case with 3.2.5 too.
Comment 5 Pavel Khaymi 2018-10-30 12:44:03 UTC
(In reply to Anthony Basile from comment #3)
> can you test eudev-3.2.7 and let me know what you find.  i just added it to
> the tree.  thanks.

bug still present in 3.2.7
need to modify 40-gentoo.rules in the gentoo repo
Comment 6 Anthony Basile gentoo-dev 2018-12-01 19:51:09 UTC
(In reply to Pavel Khaymi from comment #5)
> (In reply to Anthony Basile from comment #3)
> > can you test eudev-3.2.7 and let me know what you find.  i just added it to
> > the tree.  thanks.
> 
> bug still present in 3.2.7
> need to modify 40-gentoo.rules in the gentoo repo

Can you suggest a patch against 40-gentoo.rules?  I'd like to start moving towards stabilization.
Comment 7 Jyrki Launonen 2018-12-04 07:21:40 UTC
Created attachment 557038 [details, diff]
Patch for 40-gentoo.rules so that it is run only on "add" event.
Comment 8 Mihai Moldovan 2019-01-14 05:55:39 UTC
Even though this bug report has a patch for the 40-gentoo.rules file which might incidentally work, I somehow smell that this is not a proper solution, because other rules are also executed multiple times.

For logs, please check the files I uploaded to https://bugs.gentoo.org/618738 .

The VirtualBox rules file is also executed multiple times. While this patch logic might be put there as well to counter this bug, it feels more like a workaround. Additionally, *all* packages that install udev rules files would need to be handled that way, which is... quite difficult to accomplish.

The *actual* question from my POV is *why* rules are being processed multiple times. My hunch is that this has to be a bug in eudev, but this said, I haven't tested with systemd-udevd to see how that variant behaves.
Comment 9 Jyrki Launonen 2019-04-14 09:05:45 UTC
(In reply to Mihai Moldovan from comment #8)
> Even though this bug report has a patch for the 40-gentoo.rules file which
> might incidentally work, I somehow smell that this is not a proper solution,
> because other rules are also executed multiple times.
> 
> For logs, please check the files I uploaded to
> https://bugs.gentoo.org/618738 .
> 
> The VirtualBox rules file is also executed multiple times. While this patch
> logic might be put there as well to counter this bug, it feels more like a
> workaround. Additionally, *all* packages that install udev rules files would
> need to be handled that way, which is... quite difficult to accomplish.
> 
> The *actual* question from my POV is *why* rules are being processed
> multiple times. My hunch is that this has to be a bug in eudev, but this
> said, I haven't tested with systemd-udevd to see how that variant behaves.

See bug 618738, comment 38 for my answer. It should mostly answer your question and re-iterate what, why and how the patch in attachment 557038 [details, diff] to 40-gentoo.rules would fix the situation. The comment however goes slightly deeper and also presents an alternative fix.

My comment was mostly response to the general situation, though, an as such did not answer everything. So here, some answers to rest:

- It is totally possible that eudev has bugs and same goes with udev. The behaviour of rule executing and presented events should be same for both forks, though. Thus both eudev and udev would upon attaching an usb-device give you two events when using kernel 4.14 or newer: add and bind. Rules in 40-gentoo would be run twice, and the (in more or less correctly working) other rule would only be run once. Thus giving wrong permissions...

> Additionally, *all* packages that install udev rules files would
> need to be handled that way,

- Indeed. But that actually is how the rules are (or should be) written, so nothing new here. I would say that every rule, unless explicitly done so elsewhere, should match ACTION.


p.s. Seems I misspoke in the referred comment of the other bug that who originally suggested the goto-fix. Sorry.
p.s.2. The attachment is in patch-form, but the 40-gentoo.rules is actually a file in eudev files-dir, thus the attachment should be interpreted only as a guide to fix the file. The attachment should be not added to the tree.
Comment 10 Oliver Freyermuth 2020-06-20 19:35:29 UTC
I also ran into this just now, using =sys-fs/eudev-3.2.9. 
I wondered why pcscd is segfaulting immediately after plugging a CyberJack device, and debugging it, found that the following happens:
- First, "add" is triggered. 40-gentoo sets the "usb" group, then 99-cyberjack sets the pcscd group. 
- Then, "bind" is triggered. 40-gentoo re-sets the group to "usb", then 99-cyberjack comes, which has the "ACTION!="add"" check, and does not do anything anymore. 

Finally, pcscd tries to access the device, libusb fails (permission denied) and pcscd crashes. 

So it seems to me sys-apps/pcsc-lite with basically any USB device and eudev fails without this patch (note that "92-pcsc-ccid" also has the action check). 

It would be nice to see this patch go into the main tree to fix the issues with nut, pcsc-lite and others.
Comment 11 Sébastien P. 2021-03-07 17:43:35 UTC
Hi,

I have just switched to eudev. And same issue like other: nut/upsdrv fails to start due to bad permission:
chgrp nut /dev/bus/usb/002/007 => is a “good” workaround

I will try this patch at my next startup.