https://bugzilla.novell.com/show_bug.cgi?id=679159 https://bugzilla.novell.com/show_bug.cgi?id=679159#c1 M. S. changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |NEEDINFO InfoProvider| |coolo@novell.com Severity|Major |Critical --- Comment #1 from M. S. 2011-03-14 13:58:20 UTC --- My packages always contained a patch to the udev rules to spawn usbmuxd as noted using "usbmuxd -u". It appears obs commit 31 removed it as "not necessary". Waiting for info on why that was done otherwise will reapply to fix the issue as it basically breaks anything "iPhone/iPod Touch" related. In the longterm the solution should be to create the user and make use of it, however due to the privilege system of openSUSE, this currently does not work. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=679159 https://bugzilla.novell.com/show_bug.cgi?id=679159#c3 --- Comment #3 from M. S. 2011-03-15 11:58:23 UTC --- The problem is the privilege system. On Gentoo and others /dev/bus/usb/*/* is in the "usb" group. Adding an "usbmux" user and giving him access to the group makes usbmuxd run with dropped privileges fine and looks "elegant". On openSUSE, we have /dev/bus/usb/*/* owned by root:root. This makes it problematic to create a user and I am not sure how the "distro conform" solution should look like. I would think we should patch the udev rule and set the respective device node to "usbmux:usbmux" and also create the related user. Thoughts? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=679159 https://bugzilla.novell.com/show_bug.cgi?id=679159#c5 Ludwig Nussel changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |NEW CC| |lnussel@novell.com InfoProvider|lnussel@novell.com | --- Comment #5 from Ludwig Nussel 2011-03-15 15:17:18 CET --- I don't think using a group here is the best solution. However, neither me nor the security team has any influence on device permissions anymore anyways. Since usbmuxd is started via udev as root I'd suggest to make usbmuxd just open the device before switching uids. No need for special device permissions then. In any case usbmux needs to create the target user in %pre. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=679159 https://bugzilla.novell.com/show_bug.cgi?id=679159#c7 --- Comment #7 from M. S. 2011-03-19 11:57:46 UTC --- I am happy to implement a solution but have no idea how and the ConsoleKit/ACLs work. Might someone elaborate a bit with some rough example please? I seen that USB printer devices for instance get the "lp" group assigned. I could not determine which component changes the group ownership, some udev rule perhaps or ConsoleKit? Mind that usbmuxd handles multiple attached iDevices and hotplug of them while it's running. It only exits if the last device is gone AND no userspace clients are connected to it over a socket it exposes. Judging from the discussion so far, the option I favor now is to just enforce usbmux:usbmux ownership with an udev rule and create the user during package install (and think about other consequences in future bug reports). -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=679159 https://bugzilla.novell.com/show_bug.cgi?id=679159#c9 --- Comment #9 from M. S. 2011-03-21 08:49:49 UTC --- (In reply to comment #8)

what's wrong with opening the device before dropping privileges?

Because usbmuxd (USB multiplex daemon) opens connections to multiple iDevices and is not guaranteed to exit even once all devices are gone. For instance, you can attach one iDevice, usbmuxd opens it and drops privileges. Afterwards you attach a second one and the still running usbmuxd would not have privileges to open up that one. A typical scenario is that people replug a device quickly and since some client application might still be connected to usbmuxd's exposed socket, it won't exit and thus still run with dropped privileges being unable to access the device being plugged in again. Thus, the only thing I can think of now is that extra udev rule assigning ownership to the "usbmux" user as that would allow usbmuxd to still open any new devices while having dropped privileges overall OR just patch the udev rule as I did before and leave it running as root. I'd be interested in some ConsoleKit solution but lack the understanding how it does work... -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=679159 https://bugzilla.novell.com/show_bug.cgi?id=679159#c11 --- Comment #11 from M. S. 2011-03-21 12:31:55 UTC --- Regular startup: 1. An udev rule detects hotplug of Apple Devices and spawns usbmuxd 2. usbmuxd starts up, creates a socket /var/run/usbmuxd= 3. usbmuxd drops privileges and opens up the USB device for communication 4. Now userspace is able to talk to the socket and communicate to the device Already running usbmuxd: 1. An udev rule detects hotplug of Apple Devices and spawns (a new) usbmuxd 2. usbmuxd checks the lockfile and detects if another instance is already running 3. If another instance is running, it sends a signal to that other instance to make it scan for new USB devices to detect the newly attached device and finally exits Of course this behavior is controllable using some cli arguments to some extend. The reason for this design and the behavior of usbmuxd is that it is basically a complete FOSS implementation of the exact same daemon running on Mac OS X. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=679159 https://bugzilla.novell.com/show_bug.cgi?id=679159#c13 Marcus Meissner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |NEEDINFO InfoProvider| |maintenance@opensuse.org --- Comment #13 from Marcus Meissner 2011-03-30 13:06:32 UTC --- do you have a diff we can review? looks sensible to fix at least. +1 -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=679159 https://bugzilla.novell.com/show_bug.cgi?id=679159#c15 Marcus Meissner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |NEEDINFO InfoProvider| |maintenance@opensuse.org --- Comment #15 from Marcus Meissner 2011-03-30 14:43:43 UTC --- looks sensible. the version upgrade is probably also ok, if small. +1 -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=679159 https://bugzilla.novell.com/show_bug.cgi?id=679159#c17 Swamp Workflow Management changed: What |Removed |Added ---------------------------------------------------------------------------- Status Whiteboard| |maint:running:39783:low --- Comment #17 from Swamp Workflow Management 2011-03-30 15:30:07 UTC --- The SWAMPID for this issue is 39783. This issue was rated as low. Please submit fixed packages until 2011-04-27. Also create a patchinfo file using this link: https://swamp.suse.de/webswamp/wf/39783 -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=679159 https://bugzilla.novell.com/show_bug.cgi?id=679159#c19 --- Comment #19 from Marcus Meissner 2011-03-31 14:57:53 UTC --- we also need a submit against openSUSE:11.4:Update:Test -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=679159 https://bugzilla.novell.com/show_bug.cgi?id=679159#c21 Christian Dengler changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #21 from Christian Dengler 2011-04-08 15:38:39 UTC --- (In reply to comment #18)

I submitted the package to openSUSE:Factory and it got accepted after review. However, I am unable to access the SWAMP URL above at all (I guess it's Intranet).

Yes, Swamp is in the intranet. You can submit a patchinfo by using osc or the webinterface of the build service. I created a patchinfo now with the information from comment #18. The package is available shortly in the update-test repo for testing. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=679159 https://bugzilla.novell.com/show_bug.cgi?id=679159#c Swamp Workflow Management changed: What |Removed |Added ---------------------------------------------------------------------------- Status Whiteboard|maint:running:39783:low |. |maint:released:11.4:40077 | -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=679159 https://bugzilla.novell.com/show_bug.cgi?id=679159#c24 M. S. changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |NEEDINFO InfoProvider| |vkrevs@yahoo.com --- Comment #24 from M. S. 2011-04-22 20:10:04 UTC --- (In reply to comment #23)

Hmm, does not work for me on openSUSE 11.4/x86_64. When I connect my 2nd gen ipod, the following is displayed in /var/log/messages:

Apr 22 20:18:20 starfire kernel: [ 154.883040] fuse init (API version 7.15) Apr 22 20:18:59 starfire pulseaudio[2794]: ratelimit.c: 3 events suppressed Apr 22 20:19:08 starfire kernel: [ 203.341415] usb 2-3.1: new high speed USB device using ehci_hcd and address 7 Apr 22 20:19:08 starfire kernel: [ 203.419658] usb 2-3.1: New USB device found, idVendor=05ac, idProduct=1293 Apr 22 20:19:08 starfire kernel: [ 203.419662] usb 2-3.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 Apr 22 20:19:08 starfire kernel: [ 203.419665] usb 2-3.1: Product: iPod Apr 22 20:19:08 starfire kernel: [ 203.419668] usb 2-3.1: Manufacturer: Apple Inc. Apr 22 20:19:08 starfire kernel: [ 203.419671] usb 2-3.1: SerialNumber: 41dcefbe51f5a94cdec824f38d3118b7dead1bf0

usbmuxd is running as a the "usbnux" user: # ps -ef | grep usb root 52 2 0 20:15 ? 00:00:00 [usbhid_resumer] usbmux 748 1 0 20:15 ? 00:00:00 /usr/sbin/usbmuxd -u -U usbmux usbmux 3632 1 0 20:19 ? 00:00:00 /usr/sbin/usbmuxd -u -U usbmux vadymk 3932 2732 0 20:19 pts/2 00:00:00 grep usb

KDE only recognizes the ipod as a "camera".

Automounting of iDevices is only supported on GNOME. See: https://bugs.kde.org/show_bug.cgi?id=267701

However, when I launch Banshee from console, it finds an Apple Ipod device, however is unable to access it:

[Info 20:19:37.520] AppleDeviceSource is ignoring unmounted volume vadymk’s iPod libusb couldn't open USB device /dev/bus/usb/002/006: Permission denied. libusb requires write access to USB device nodes. Device 0 (VID=05ac and PID=1293) is a Apple iPod Touch 2nd Gen.

# rpm -q iproxy libusbmuxd1 usbmuxd iproxy-1.0.7-3.3.1.x86_64 libusbmuxd1-1.0.7-3.3.1.x86_64 usbmuxd-1.0.7-3.3.1.x86_64

Please check with lsusb if /dev/bus/usb/002/006 is really your iPod device and run "l /dev/bus/usb/002/" to view the ownership of the device file (it must be usbmux:root). Please report if the file "/lib/udev/rules.d/85-usbmuxd.rules" contains the option OWNER="usbmux" on your system. If you are able to run "ideviceinfo", which should output a list of information, your libimobiledevice setup is working fine and this bug is fixed. You should then file a bug for KDE or Banshee regarding this issue. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=679159 https://bugzilla.novell.com/show_bug.cgi?id=679159#c26 M. S. changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |FIXED --- Comment #26 from M. S. 2011-05-01 19:37:04 UTC --- (In reply to comment #25)

Hi M.S.! Thank you for such a prompt reply. You are right - I was too hasty to report this - /dev/bus/usb/002/006 is not the iPod. The iPod is /dev/bus/usb/002/007. It's ownership is correct:

l /dev/bus/usb/002/007 crw-rw-r--+ 1 usbmux root 189, 134 Apr 22 21:13 /dev/bus/usb/002/007

And /lib/udev/rules.d/85-usbmuxd.rules does contain the OWNER="usbmux" option.

However, I can only successfully run ideviceinfo as root. When running it as a normal user, I get

$ ideviceinfo GNUTLS ERROR: A TLS packet with unexpected length was received.

Is that expected behaviour?

Run "idevicepair unpair" then "idevicepair pair". This should fix your issue. Make sure to have libimobiledevice >= 1.0.4. Other than that, in the initial context of this bug, the issue is resolved. If you still have issues feel free to post them in the upstream bugtracker: http://libiphone.lighthouseapp.com/ -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.