http://bugzilla.suse.com/show_bug.cgi?id=938659 http://bugzilla.suse.com/show_bug.cgi?id=938659#c1 --- Comment #1 from Markus Elfring --- (In reply to Markus Elfring from comment #0)

Would you like to help me further with the determination and setting of appropriate permissions for a working print system configuration?

Did I expect too much that the YaST printer setup will keep or adjust the members of the system group "lp" appropriately after another printer connection so that device discovery problems can be better avoided? https://www.cups.org/pipermail/cups/2014-September/026459.html -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=938659 http://bugzilla.suse.com/show_bug.cgi?id=938659#c2 Johannes Meixner changed: What |Removed |Added ---------------------------------------------------------------------------- URL| |https://bugzilla.suse.com/s | |how_bug.cgi?id=920937#c23 CC| |jsmeix@suse.com, | |Markus.Elfring@web.de Component|Printing |Other Found By|--- |Community User Assignee|jsmeix@suse.com |bnc-team-screening@forge.pr | |ovo.novell.com Summary|Indication "Access error" |LIBUSB_ERROR_ACCESS error |from "libusb_open" during |(insufficient permissions) |printer device detection |from "libusb_open" during | |USB printer device | |detection QA Contact|jsmeix@suse.com |qa-bugs@suse.de Flags| |needinfo?(Markus.Elfring@we | |b.de) --- Comment #2 from Johannes Meixner --- Your initial description in comment#0 matches https://bugzilla.suse.com/show_bug.cgi?id=920937#c23 and subsequent comments. A bit later your call of /usr/lib/cups/backend/usb works so that your symptoms also match the symptoms in https://bugzilla.suse.com/show_bug.cgi?id=920937#c5 where for Saša Janiška /usr/lib/cups/backend/usb had worked but he also got the "Failed to open device, code: -3". In bug#920937 I wrote several times that I cannot help with such issues, see https://bugzilla.suse.com/show_bug.cgi?id=920937#c7 https://bugzilla.suse.com/show_bug.cgi?id=920937#c35 https://bugzilla.suse.com/show_bug.cgi?id=920937#c43 https://bugzilla.suse.com/show_bug.cgi?id=920937#c66 Regarding "YaST printer setup will keep or adjust the members of the system group 'lp' appropriately": The YaST printer setup does not and will not change system groups. In general the YaST printer setup does not and will not change basic system settings. Accordingly the YaST printer setup also does not and will not change device node permissions. That is done and has to be done by udev. For example on my Tumbleweed system I get: ---------------------------------------------------------------------------- # lsusb Bus 001 Device 002: ID 04f9:0022 Brother Industries, Ltd HL-5150D series ... # ls -l /dev/bus/usb/001/002 crw-rw-r-- 1 root lp 189, 1 Jul 20 11:42 /dev/bus/usb/001/002 # lpinfo -v ... direct usb://Brother/HL-5150D%20series?serial=F5J889574 ... ---------------------------------------------------------------------------- Markus Elfring what shows "ls -l /dev/bus/usb//" for your USB printer device on your system? The device node /dev/bus/usb/001/002 has "rw-rw-r-- 1 root lp" because udev sets it for USB printer devices as far as I know via /usr/lib/udev/rules.d/50-udev-default.rules and /usr/lib/udev/rules.d/99-systemd.rules I think - but I am not at all a udev expert - that in /usr/lib/udev/rules.d/50-udev-default.rules the line (shown wrapped here - actually one line): ----------------------------------------------------------------------------- SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", ENV{ID_USB_INTERFACES}=="*:0701??:*", GROUP="lp" ----------------------------------------------------------------------------- sets group "lp" for USB printer devices. Perhaps in special cases one may have to add MODE="0664" to set device node access permissions explicitly to "rw-rw-r--" as follows (all on one line shown wrapped only here): ----------------------------------------------------------------------------- SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", ENV{ID_USB_INTERFACES}=="*:0701??:*", GROUP="lp", MODE="0664" ----------------------------------------------------------------------------- Perhaps in special cases ENV{ID_USB_INTERFACES}=="*:0701??:*" does not match for a particular USB printer device so that one may have to use something else that matches? In general when something with udev does not work as it should I cannot help because I am not at all a sufficient udev expert. As written in https://bugzilla.suse.com/show_bug.cgi?id=920937#c43 https://bugzilla.suse.com/show_bug.cgi?id=920937#c66 https://bugzilla.suse.com/show_bug.cgi?id=920937#c113 https://bugzilla.suse.com/show_bug.cgi?id=920937#c130 I still think that the root cause of this issue is very likely not in a "Printing" package but elsewhere so that this issue does not belong to the Bugzilla component "Printing". -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=938659 http://bugzilla.suse.com/show_bug.cgi?id=938659#c4 Johannes Meixner changed: What |Removed |Added ---------------------------------------------------------------------------- Component|Other |Basesystem Summary|LIBUSB_ERROR_ACCESS error |udev does not set |(insufficient permissions) |"rw-rw-r-- root lp" for |from "libusb_open" during |device node for all USB |USB printer device |printers (works mostly but |detection |some are missing) Flags| |needinfo?(Markus.Elfring@we | |b.de) --- Comment #4 from Johannes Meixner --- That "ls -l /dev/bus/usb//" shows "rw-rw---- root users" is unexpected and perhaps this is really the root cause of all. I cannot tell how to change udev rules so that it shows up as "rw-rw-r-- root lp" automatically. But only to verify if that unexpected "rw-rw---- root users" is the root cause, you can change owner, group and permissions on USB device node files by usual "chown" and "chmod" commands as long as you do not disconnect and reconnect the USB device as follows e.g. on my Tumbleweed system: --------------------------------------------------------------------------- # ls -l /dev/bus/usb/001/002 crw-rw-r-- 1 root lp 189, 1 Jul 20 13:25 /dev/bus/usb/001/002 # chown root:users /dev/bus/usb/001/002 # chmod 0660 /dev/bus/usb/001/002 # ls -l /dev/bus/usb/001/002 crw-rw---- 1 root users 189, 1 Jul 20 13:25 /dev/bus/usb/001/002 # /usr/lib/cups/backend/usb 2>/dev/null direct usb://Brother/HL-5150D%20series?serial=F5J889574 ... # lpinfo -v | grep usb: [no output] # chmod 0666 /dev/bus/usb/001/002 # lpinfo -v | grep usb: direct usb://Brother/HL-5150D%20series?serial=F5J889574 # chmod 0664 /dev/bus/usb/001/002 # lpinfo -v | grep usb: [no output] # chown root:lp /dev/bus/usb/001/002 # lpinfo -v | grep usb: direct usb://Brother/HL-5150D%20series?serial=F5J889574 # ls -l /dev/bus/usb/001/002 crw-rw-r-- 1 root lp 189, 1 Jul 20 14:39 /dev/bus/usb/001/002 --------------------------------------------------------------------------- Now I can reproduce it! With "crw-rw---- root users" running /usr/lib/cups/backend/usb as root works as expected because root has unlimited permmissions. With "crw-rw---- root users" it does no longer work for "lpinfo -v | grep usb:". Each time when you disconnect and reconnect a USB device a new USB device node file gets created by udev. Each time when you disconnect and reconnect your USB printer you would have to do again # chown root:lp /dev/bus/usb// # chmod 0664 /dev/bus/usb// Markus Elfring please report if it works for you after manually as root # chown root:lp /dev/bus/usb// # chmod 0664 /dev/bus/usb// -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=938659 http://bugzilla.suse.com/show_bug.cgi?id=938659#c6 --- Comment #6 from Markus Elfring --- (In reply to Johannes Meixner from comment #2)

I think - but I am not at all a udev expert - that in /usr/lib/udev/rules.d/50-udev-default.rules

Does a configuration file like "/usr/lib/udev/rules.d/70-printers.rules" need eventually another look together with the software package "udev-configure-printer 1.5.7-2.1"? -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=938659 Dr. Werner Fink changed: What |Removed |Added ---------------------------------------------------------------------------- URL|https://bugzilla.suse.com/s |http://rudin.suse.de:8888/s |how_bug.cgi?id=920937#c23 |how_bug.cgi?id=920937#c23 CC| |crrodriguez@opensuse.org, | |jengelh@inai.de -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=938659 http://bugzilla.suse.com/show_bug.cgi?id=938659#c8 --- Comment #8 from Markus Elfring --- (In reply to Johannes Meixner from comment #7)

From my point of view it is more basic functionality that does not work for your particular USB printer.

Do I need to check any more details from my system configuration if I look at the following information? Sonne:~ # lsusb -s 3 && udevadm info -a /dev/bus/usb/001/003 | grep Class Bus 001 Device 003: ID 0482:063e Kyocera Corp. ATTR{bDeviceSubClass}=="00" ATTR{bDeviceClass}=="00" ATTRS{bDeviceSubClass}=="00" ATTRS{bDeviceClass}=="09" Where should the item "ATTR{bInterfaceClass}" get set usually? -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=938659 http://bugzilla.suse.com/show_bug.cgi?id=938659#c10 --- Comment #10 from Markus Elfring --- (In reply to Johannes Meixner from comment #7)

From my point of view it is more basic functionality that does not work for your particular USB printer.

I have connected the model "Stylus C84" with my Tumbleweed system for another test. elfring@Sonne:~> lsusb -s 2 && target=/dev/bus/usb/003/002 && ls -l $target && udevadm info -a $target | grep Class Bus 003 Device 002: ID 04b8:0005 Seiko Epson Corp. Printer crw-rw-r-- 1 root lp 189, 257 22. Jul 08:07 /dev/bus/usb/003/002 ATTR{bDeviceSubClass}=="00" ATTR{bDeviceClass}=="00" ATTRS{bDeviceSubClass}=="00" ATTRS{bDeviceClass}=="09" Does an information like "ATTR{bInterfaceClass}" get eventually displayed on your development or production systems? -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=938659 http://bugzilla.suse.com/show_bug.cgi?id=938659#c12 --- Comment #12 from Dr. Werner Fink --- (In reply to Johannes Meixner from comment #11) For me this looks like the printer with the wrong permissions and owner ship is not part of something like a data base (e.g. /usr/share/usb.ids) and/or is missing hint in its vendor description that it *is* a printer. On the other hand it could be that the printer is a 3in1 or 4in1 model which is currently not a printer but a scanner. We have lsusb as well as lsscsi but not a lslp to check this. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=938659 http://bugzilla.suse.com/show_bug.cgi?id=938659#c14 --- Comment #14 from Markus Elfring --- (In reply to Dr. Werner Fink from comment #12)

For me this looks like the printer with the wrong permissions and owner ship is not part of something like a data base (e.g. /usr/share/usb.ids) and/or is missing hint in its vendor description that it *is* a printer.

Is there any software component which depends still on the repetition of a device type in the product name? How many device attributes should be usually checked for ordinary system operation? Do you know any similar configuration challenges from other device domains? -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=938659 http://bugzilla.suse.com/show_bug.cgi?id=938659#c16 --- Comment #16 from Markus Elfring --- (In reply to Dr. Werner Fink from comment #15)

Please show the result of

udevadm info -x /dev/bus/usb/001/003 | grep ID_USB_INTERFACES

E: ID_USB_INTERFACES=:070102: -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=938659 http://bugzilla.suse.com/show_bug.cgi?id=938659#c18 Dr. Werner Fink changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |needinfo?(Markus.Elfring@we | |b.de) --- Comment #18 from Dr. Werner Fink --- (In reply to Markus Elfring from comment #16) That means that it is likly that the rule has matched. If so it might be that the rule will be overwritten by na other rule. Is this Kyrocera a so called 3in1 or 4in1 model and/or has aybe an own card bridge to read memory cards? If you switch off your printer and then run in an terminal the command udevadm monitor --env --kernel udev to switch on again your printer, what does you see? -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=938659 http://bugzilla.suse.com/show_bug.cgi?id=938659#c20 --- Comment #20 from Johannes Meixner --- I also digged in the systemd-221 sources to find documentation about the meaning of ENV{ID_USB_INTERFACES}=="*:0701??:*". The only non-udev-rules file where ID_USB_INTERFACES is found is src/udev/udev-builtin-usb_id.c and therein not any helpful comment which means one has to parse the code to find out what ID_USB_INTERFACES contains which leads to: ------------------------------------------------------------------------- static int dev_if_packed_info( ... ... if (snprintf(if_str, 8, ":%02x%02x%02x", desc->bInterfaceClass, desc->bInterfaceSubClass, desc->bInterfaceProtocol) != 7) continue; ------------------------------------------------------------------------- I.e. ID_USB_INTERFACES contains a concatenation of what "lsusb -v" shows as bInterfaceClass bInterfaceSubClass bInterfaceProtocol FYI on my Tumbleweed system: ------------------------------------------------------------------------- # lsusb -v -s 001:002 Bus 001 Device 002: ID 04f9:0022 Brother Industries, Ltd HL-5150D series ... bInterfaceClass 7 Printer bInterfaceSubClass 1 Printer bInterfaceProtocol 2 Bidirectional ... # udevadm info -x /dev/bus/usb/001/002 \ | egrep 'SUBSYSTEM|DEVTYPE|ID_USB_INTERFACES' E: DEVTYPE=usb_device E: ID_USB_INTERFACES=:070102: E: SUBSYSTEM=usb ------------------------------------------------------------------------- -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=938659 http://bugzilla.suse.com/show_bug.cgi?id=938659#c22 --- Comment #22 from Markus Elfring --- (In reply to Dr. Werner Fink from comment #21)

this seems that

SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", ENV{ID_USB_INTERFACES}=="*:0701??:*", GROUP="lp"

will not be matched by

I wonder how this could happen with the following information. Sonne:~ # udevadm info -x /dev/bus/usb/001/004 | egrep 'SUBSYSTEM|DEVTYPE|ID_USB_INTERFACES' E: DEVTYPE=usb_device E: ID_USB_INTERFACES=:070102: E: SUBSYSTEM=usb

to see if this may match

I am going to experiment with corresponding udev rule additions a bit later. How often do you need to fiddle with the affected rule collection in special ways on your test and development systems? -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=938659 http://bugzilla.suse.com/show_bug.cgi?id=938659#c24 --- Comment #24 from Markus Elfring --- (In reply to Dr. Werner Fink from comment #21)

to see if this may match

Do you know if there is a special software test module available which I could configure like it is usual with real printers? How are the chances to reproduce the issue I stumbled on without switching external hardware on? Can the affected file permission settings be also checked by a kind of simulation for the desired device addition and activation? -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=938659 http://bugzilla.suse.com/show_bug.cgi?id=938659#c29 --- Comment #29 from Dr. Werner Fink --- (In reply to Johannes Meixner from comment #28) Maybe it would help to replace the line SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", ENV{ID_USB_INTERFACES}=="*:0701??:*", GROUP="lp" with SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", ENV{ID_USB_INTERFACES}=="*:0701??:*", MODE:="0664", GROUP:="lp" that means with colon a later override will be avoided -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=938659 http://bugzilla.suse.com/show_bug.cgi?id=938659#c31 --- Comment #31 from Markus Elfring --- (In reply to Markus Elfring from comment #30)

I would prefer an other approach to drill down into involved details.

Does the implementation of the function "udev_event_execute_rules" need another source code review for potential improvements around changes from the commit 912541b0246ef315d4d851237483b98c9dd3f992 on 2012-01-10? https://github.com/systemd/systemd/blob/master/src/udev/udev-event.c#L894 -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=938659 http://bugzilla.suse.com/show_bug.cgi?id=938659#c33 --- Comment #33 from Markus Elfring --- (In reply to Markus Elfring from comment #30)

I would prefer an other approach to drill down into involved details.

Would you like to help me to get a core dump from a child process of a program variant? Do you find the request "Clarification around a segmentation fault from an udevd worker" interesting for a further problem analysis? http://lists.freedesktop.org/archives/systemd-devel/2015-July/033698.html http://article.gmane.org/gmane.comp.sysutils.systemd.devel/33608 -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=938659 http://bugzilla.suse.com/show_bug.cgi?id=938659#c35 --- Comment #35 from Markus Elfring --- Created attachment 642379 --> http://bugzilla.suse.com/attachment.cgi?id=642379&action=edit Debug output from "systemd-udevd" for a connection with the model "P6021cdn" (In reply to Johannes Meixner from comment #28) Another test run with enhanced debug output for a P6021cdn connection: Sonne:/home/elfring/Projekte/Bau/systemd # systemctl stop systemd-udevd.service systemd-udevd-kernel.socket systemd-udevd-control.socket && ./systemd-udevd --debug 2> udevd_log-20150729_1700.txt -- You are receiving this mail because: You are on the CC list for the bug.

From my point of view (i.e. from a printing system point of view)

http://bugzilla.suse.com/show_bug.cgi?id=938659 http://bugzilla.suse.com/show_bug.cgi?id=938659#c37 Johannes Meixner changed: What |Removed |Added ---------------------------------------------------------------------------- URL|http://rudin.suse.de:8888/s |https://bugzilla.opensuse.o |how_bug.cgi?id=920937#c23 |rg/show_bug.cgi?id=920937#c | |23 Component|Basesystem |Other Summary|udev does not set |51-android.rules overwrites |"rw-rw-r-- root lp" for |default "rw-rw-r-- root lp" |device node for all USB |for device node for some |printers (works mostly but |USB printers (e.g. for all |some are missing) |Kyocera printers) Flags| |needinfo?(Markus.Elfring@we | |b.de) --- Comment #37 from Johannes Meixner --- Your attachment#642376 for "Stylus C84" contains (excerpt): ---------------------------------------------------------------------------- $ egrep ' MODE | GROUP | set permissions ' udevd_log-20150729_1644.txt .../home/elfring/Projekte/systemd/lokal/src/udev/udev-rules.c:2346: MODE 0664 /usr/lib/udev/rules.d/50-udev-default.rules:38 .../home/elfring/Projekte/systemd/lokal/src/udev/udev-rules.c:2334: GROUP 7 /usr/lib/udev/rules.d/50-udev-default.rules:52 .../home/elfring/Projekte/systemd/lokal/src/udev/udev-node.c:281: set permissions /dev/bus/usb/003/010, 020664, uid=0, gid=7 ---------------------------------------------------------------------------- In contrast your aattachment#642379 for "P6021cdn" contains (excerpt): ---------------------------------------------------------------------------- $ egrep ' MODE | GROUP | set permissions ' udevd_log-20150729_1700.txt .../home/elfring/Projekte/systemd/lokal/src/udev/udev-rules.c:2346: MODE 0664 /usr/lib/udev/rules.d/50-udev-default.rules:38 .../home/elfring/Projekte/systemd/lokal/src/udev/udev-rules.c:2334: GROUP 7 /usr/lib/udev/rules.d/50-udev-default.rules:52 .../home/elfring/Projekte/systemd/lokal/src/udev/udev-rules.c:2334: GROUP 100 /usr/lib/udev/rules.d/51-android.rules:26 .../home/elfring/Projekte/systemd/lokal/src/udev/udev-rules.c:2346: MODE 0660 /usr/lib/udev/rules.d/51-android.rules:26 .../home/elfring/Projekte/systemd/lokal/src/udev/udev-node.c:281: set permissions /dev/bus/usb/001/020, 020660, uid=0, gid=100 ---------------------------------------------------------------------------- This proves that for the "P6021cdn" a rule in a /usr/lib/udev/rules.d/51-android.rules file matches for the "P6021cdn" which changes MODE 0664 GROUP 7 to GROUP 100 MODE 0660 Markus Elfring, this rule is what you wrote in your comment#36. The rule in your comment#36 applies to any Kyocera devices and because 51-android.rules is alpabetically after 50-udev-default.rules the 51-android.rules are applied after the ones in 50-udev-default.rules. There is no bug in udev. It works exactly as the udev rules on your Tumbleweed system specify. The root cause is in the package that provides 51-android.rules because it contains a rule that applies to any Kyocera devices. I cannot decide if that rule is right or wrong. At least for Kyocera USB printers it seems to be wrong because it makes normal usage by the printing system (via user lp group lp) impossible - but I cannot decide if that it intended. that rule in 51-android.rules is plain wrong. On my Tumbleweed system I do not have a /usr/lib/udev/rules.d/51-android.rules file. Markus Elfring, where does the /usr/lib/udev/rules.d/51-android.rules file come from? I.e. what results on your system # rpm -qf /usr/lib/udev/rules.d/51-android.rules and then when you got its RPM package name what results # rpm -qi -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=938659 http://bugzilla.suse.com/show_bug.cgi?id=938659#c38 Johannes Meixner changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|systemd-maintainers@suse.de |dmitry@roshchin.org --- Comment #38 from Johannes Meixner --- /usr/lib/udev/rules.d/51-android.rules is provided by the android-tools RPM. I re-assign the issue to its maintainer: ------------------------------------------------------------------------- $ osc maintainer android-tools Defined in package: hardware/android-tools bugowner of android-tools : - maintainer of android-tools : Dmitry_R $ osc whois Dmitry_R Dmitry_R: "Dmitry Roshchin" ------------------------------------------------------------------------- -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=938659 http://bugzilla.suse.com/show_bug.cgi?id=938659#c39 Dr. Werner Fink changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |systemd-maintainers@suse.de --- Comment #39 from Dr. Werner Fink --- Those rules are used to enable the androids SDK environment to access Android systems via ADB (Android Debug Bridge). IMHO those rules should become active only if a real Android system becomes attached via USB. To modify permissions and/or owner chips of USB sub systems of e.g. a printer is a bad idea (IMHO). -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=938659 http://bugzilla.suse.com/show_bug.cgi?id=938659#c41 Johannes Meixner changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dmitry@roshchin.org, | |security-team@suse.de Component|Other |Security --- Comment #41 from Johannes Meixner --- Dmitry Roshchin, I did osc getbinaries openSUSE:Factory android-tools standard i586 and got android-tools-5.1.1_r8-1.1.i586.rpm that contains /usr/lib/udev/rules.d/51-android.rules -------------------------------------------------------------------------- #egrep -v '^$|^#' /usr/lib/udev/rules.d/51-android.rules SUBSYSTEM=="usb", ATTR{idVendor}=="0502", TAG+="uaccess" SUBSYSTEM=="usb", ATTR{idVendor}=="0b05", TAG+="uaccess" SUBSYSTEM=="usb", ATTR{idVendor}=="413c", TAG+="uaccess" SUBSYSTEM=="usb", ATTR{idVendor}=="0489", TAG+="uaccess" SUBSYSTEM=="usb", ATTR{idVendor}=="04c5", TAG+="uaccess" SUBSYSTEM=="usb", ATTR{idVendor}=="04c5", TAG+="uaccess" SUBSYSTEM=="usb", ATTR{idVendor}=="091e", TAG+="uaccess" SUBSYSTEM=="usb", ATTR{idVendor}=="18d1", TAG+="uaccess" SUBSYSTEM=="usb", ATTR{idVendor}=="201E", TAG+="uaccess" SUBSYSTEM=="usb", ATTR{idVendor}=="109b", TAG+="uaccess" SUBSYSTEM=="usb", ATTR{idVendor}=="0bb4", TAG+="uaccess" SUBSYSTEM=="usb", ATTR{idVendor}=="12d1", TAG+="uaccess" SUBSYSTEM=="usb", ATTR{idVendor}=="8087", TAG+="uaccess" SUBSYSTEM=="usb", ATTR{idVendor}=="24e3", TAG+="uaccess" SUBSYSTEM=="usb", ATTR{idVendor}=="2116", TAG+="uaccess" SUBSYSTEM=="usb", ATTR{idVendor}=="0482", TAG+="uaccess" SUBSYSTEM=="usb", ATTR{idVendor}=="17ef", TAG+="uaccess" SUBSYSTEM=="usb", ATTR{idVendor}=="1004", TAG+="uaccess" SUBSYSTEM=="usb", ATTR{idVendor}=="22b8", TAG+="uaccess" SUBSYSTEM=="usb", ATTR{idVendor}=="0e8d", TAG+="uaccess" SUBSYSTEM=="usb", ATTR{idVendor}=="0409", TAG+="uaccess" SUBSYSTEM=="usb", ATTR{idVendor}=="2080", TAG+="uaccess" SUBSYSTEM=="usb", ATTR{idVendor}=="0955", TAG+="uaccess" SUBSYSTEM=="usb", ATTR{idVendor}=="2257", TAG+="uaccess" SUBSYSTEM=="usb", ATTR{idVendor}=="10a9", TAG+="uaccess" SUBSYSTEM=="usb", ATTR{idVendor}=="1d4d", TAG+="uaccess" SUBSYSTEM=="usb", ATTR{idVendor}=="0471", TAG+="uaccess" SUBSYSTEM=="usb", ATTR{idVendor}=="04da", TAG+="uaccess" SUBSYSTEM=="usb", ATTR{idVendor}=="05c6", TAG+="uaccess" SUBSYSTEM=="usb", ATTR{idVendor}=="1f53", TAG+="uaccess" SUBSYSTEM=="usb", ATTR{idVendor}=="04e8", TAG+="uaccess" SUBSYSTEM=="usb", ATTR{idVendor}=="04dd", TAG+="uaccess" SUBSYSTEM=="usb", ATTR{idVendor}=="054c", TAG+="uaccess" SUBSYSTEM=="usb", ATTR{idVendor}=="0fce", TAG+="uaccess" SUBSYSTEM=="usb", ATTR{idVendor}=="0fce", TAG+="uaccess" SUBSYSTEM=="usb", ATTR{idVendor}=="2340", TAG+="uaccess" SUBSYSTEM=="usb", ATTR{idVendor}=="0930", TAG+="uaccess" SUBSYSTEM=="usb", ATTR{idVendor}=="19d2", TAG+="uaccess" -------------------------------------------------------------------------- As far as I see those rules are in two ways wrong: 1. They apply unconditionally for all USB devices of those vendors. When vendors make various kind of USB devices such unconditioned rules could cause conflicts with other rules that are inteded for particular kind of USB devices as in this bug here. 2. They grant unconditionally for all USB devices of those vendors normal user access (via TAG+="uaccess") and that could be a severe security issue but I am not a sufficient security expert to make an educated statement here. Therefore I change the Bugzilla component to "security" so that our security team could have a look. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=938659 http://bugzilla.suse.com/show_bug.cgi?id=938659#c42 Johannes Meixner changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|dmitry@roshchin.org |crrodriguez@opensuse.org --- Comment #42 from Johannes Meixner --- The RPM changelog of android-tools-5.1.1_r8-1.1.i586.rpm shows: ----------------------------------------------------------------------- * Tue Jun 23 2015 crrodriguez@opensuse.org - 51-android.rules: Use TAG+="uaccess" instead of using group/mode access control. ----------------------------------------------------------------------- Accordingy it seems crrodriguez@opensuse.org is the more appropriate assignee for issues with 51-android.rules -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=938659 http://bugzilla.suse.com/show_bug.cgi?id=938659#c44 --- Comment #44 from Dr. Werner Fink --- (In reply to Johannes Meixner from comment #41) Now it uses uaccess instead of hard coded group amd permissions. This is a way better. With this the access will be allowed if the user does a simple login aka has a local login session. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=938659 http://bugzilla.suse.com/show_bug.cgi?id=938659#c46 --- Comment #46 from Markus Elfring --- (In reply to Dean Martin from comment #43)

IMHO it would make sense to adjust the rule in 50-udev-default.rules so that overrides from later rules are prevented as Fink Werner already suggested

Do any printing devices need any more special permissions here? When would you reuse another rule file for a model collection? -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=938659 http://bugzilla.suse.com/show_bug.cgi?id=938659#c48 --- Comment #48 from Johannes Meixner --- Only a side note: There are duplicate rules in current 51-android.rules: --------------------------------------------------------------------------- SUBSYSTEM=="usb", ATTR{idVendor}=="04c5", TAG+="uaccess" SUBSYSTEM=="usb", ATTR{idVendor}=="0fce", TAG+="uaccess" --------------------------------------------------------------------------- Those rules appear twice in 51-android.rules. Perhaps they could be made unique as follows: --------------------------------------------------------------------------- # Fujitsu and Fujitsu Toshiba SUBSYSTEM=="usb", ATTR{idVendor}=="04c5", TAG+="uaccess" ... # Sony Ericsson and Sony Mobile Communications SUBSYSTEM=="usb", ATTR{idVendor}=="0fce", TAG+="uaccess" --------------------------------------------------------------------------- -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=938659 http://bugzilla.suse.com/show_bug.cgi?id=938659#c50 --- Comment #50 from Cristian Rodríguez --- (In reply to Johannes Meixner from comment #47)

I think the real solution would be more specific conditions in 51-android.rules so that those rules only apply for the specific devices for what android-tools is meant to be used.

Yes, the problem is on how this rules were collected or generated..we need to correct that. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=938659 http://bugzilla.suse.com/show_bug.cgi?id=938659#c52 --- Comment #52 from Johannes Meixner --- Regarding comment#43 "50-udev-default.rules ... overrides from later rules are prevented": I don't think that a "default.rules" file should prevent overrides from later rules because - as far as I understand - this would be against how the udev rules system is meant to be used. I think a "default.rules" file by definition sets only defaults and intentionally for special cases defaults can be overridden by later rules. In this particular case the actual problem is that later rules falsely override default rules (because those later rules are not "for special cases"). I think only the actual problem should be solved. But if udev/systemd upstream agrees it is correct to enforce the USB printer device default rules in 50-udev-default.rules then it is of course o.k. to do that (I am not a udev expert to make such decisions). -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=938659 http://bugzilla.suse.com/show_bug.cgi?id=938659#c54 --- Comment #54 from Markus Elfring --- (In reply to Johannes Meixner from comment #52)

In this particular case the actual problem is that later rules falsely override default rules (because those later rules are not "for special cases").

Are there any sanity checks available against more inappropriate settings from the rule collection? (In reply to Cristian Rodríguez from comment #53)

It would have to be generated from usb_vendors.c or whatever replaces it in current adb releases.

Would you like to refer to any content management system for these source files? -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=938659 http://bugzilla.suse.com/show_bug.cgi?id=938659#c56 --- Comment #56 from Markus Elfring --- (In reply to Johannes Meixner from comment #52)

In this particular case the actual problem is that later rules falsely override default rules (because those later rules are not "for special cases").

I could try to achieve better settings also by an additional udev rule file, couldn't I? Further ideas: * Have you been looking for solutions around similar system configuration challenges already? * Do we need the combination of the device access permissions from the groups "lp" and "plugdev" in the discussed use case? * Which is the recommended way to extend access control lists by udev interfaces so that functionality like "printing", "picture scanning" and "Android software development/debugging" can be used together? (Are corresponding device interfaces cleanly separated?) -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=938659 http://bugzilla.suse.com/show_bug.cgi?id=938659#c64 --- Comment #64 from Jan Engelhardt --- Oh well, it already is in its package (android-tools). -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=938659 http://bugzilla.suse.com/show_bug.cgi?id=938659#c66 --- Comment #66 from Dmitry Roshchin --- And looks like adb works fine with udev rules from libmtp9, so we can drop 51-android.rules totally, tested on my Sony Z3 compact. -- You are receiving this mail because: You are on the CC list for the bug.