Bug 2938 - Permissions on USB device (Camera) not set properly
Summary: Permissions on USB device (Camera) not set properly
Status: RESOLVED WONTFIX
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: 1
Hardware: All Linux
Priority: Normal normal
Target Milestone: ---
Assignee: Mageia Bug Squad
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 2937
  Show dependency tree / graph
 
Reported: 2011-10-04 21:26 CEST by Herbert Poetzl
Modified: 2012-12-02 14:32 CET (History)
6 users (show)

See Also:
Source RPM: udev-166-5.mga1.src.rpm
CVE:
Status comment:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Description Herbert Poetzl 2011-10-04 21:26:23 CEST 
Description of problem:
Connecting the Olympus C-4040-Zoom via USB leads to a device node only accessible for root:root, instead of access for the logged in user.

Version-Release number of selected component (if applicable):


How reproducible:
always

Steps to Reproduce:
1.plug in USB camera
2.check device permissions
3.



Bus 002 Device 002: ID 07b4:0105 Olympus Optical Co., Ltd Camedia C-310Z/C-700/C-750UZ/C-755/C-765UZ/C-3040/C-4000/C-5050Z/D-560/C-3020Z Zoom Camera
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               1.10
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0         8
  idVendor           0x07b4 Olympus Optical Co., Ltd
  idProduct          0x0105 Camedia C-310Z/C-700/C-750UZ/C-755/C-765UZ/C-3040/C-4000/C-5050Z/D-560/C-3020Z Zoom Camera
  bcdDevice            1.00
  iManufacturer           1 
  iProduct                2 
  iSerial                 3 
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           32
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0 
    bmAttributes         0xc0
      Self Powered
    MaxPower                0mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass         8 Mass Storage
      bInterfaceSubClass      6 SCSI
      bInterfaceProtocol     80 Bulk (Zip)
      iInterface              0 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x04  EP 4 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x83  EP 3 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               0
Comment 1 Marja Van Waes 2011-12-05 20:57:24 CET 
@ blino or @pterjan or @tv

Is libgphoto the package that is responsible for setting the permissions? If not, which package is it?

CC: (none) => mageia, marja11, pterjan, thierry.vignaud
Source RPM: ??? => libgphoto2-2.4.10.1-1.mga1

Comment 2 Herbert Poetzl 2011-12-05 21:08:56 CET 
most likely it's udev, i.e. one of the udev rules which _should_ set the proper permissions but doesn't ....
Thierry Vignaud 2011-12-05 21:15:05 CET

CC: (none) => mageia

Comment 3 Colin Guthrie 2011-12-05 21:30:59 CET 
Yup, it's probably udev, especially as this is a USB Mass storage rather than PTP.

Can you attach the relevant bit from:
udevadm info --export-db
Comment 4 Herbert Poetzl 2011-12-26 03:52:57 CET 
P: /devices/pci0000:00/0000:00:1d.7/usb1/1-2/1-2.2
N: bus/usb/001/008
E: UDEV_LOG=3
E: DEVPATH=/devices/pci0000:00/0000:00:1d.7/usb1/1-2/1-2.2
E: MAJOR=189
E: MINOR=7
E: DEVNAME=/dev/bus/usb/001/008
E: DEVTYPE=usb_device
E: DRIVER=usb
E: DEVICE=/proc/bus/usb/001/008
E: PRODUCT=7b4/105/100
E: TYPE=0/0/0
E: BUSNUM=001
E: DEVNUM=008
E: SUBSYSTEM=usb
E: ID_VENDOR=OLYMPUS
E: ID_VENDOR_ENC=OLYMPUS
E: ID_VENDOR_ID=07b4
E: ID_MODEL=C-4040ZOOM
E: ID_MODEL_ENC=C-4040ZOOM
E: ID_MODEL_ID=0105
E: ID_REVISION=0100
E: ID_SERIAL=OLYMPUS_C-4040ZOOM_000197314779
E: ID_SERIAL_SHORT=000197314779
E: ID_BUS=usb
E: ID_USB_INTERFACES=:080650:

P: /devices/pci0000:00/0000:00:1d.7/usb1/1-2/1-2.2/1-2.2:1.0
E: UDEV_LOG=3
E: DEVPATH=/devices/pci0000:00/0000:00:1d.7/usb1/1-2/1-2.2/1-2.2:1.0
E: DEVTYPE=usb_interface
E: DRIVER=usb-storage
E: DEVICE=/proc/bus/usb/001/008
E: PRODUCT=7b4/105/100
E: TYPE=0/0/0
E: INTERFACE=8/6/80
E: MODALIAS=usb:v07B4p0105d0100dc00dsc00dp00ic08isc06ip50
E: SUBSYSTEM=usb

P: /devices/pci0000:00/0000:00:1d.7/usb1/1-2/1-2.2/1-2.2:1.0/host6
E: UDEV_LOG=3
E: DEVPATH=/devices/pci0000:00/0000:00:1d.7/usb1/1-2/1-2.2/1-2.2:1.0/host6
E: DEVTYPE=scsi_host
E: SUBSYSTEM=scsi

P: /devices/pci0000:00/0000:00:1d.7/usb1/1-2/1-2.2/1-2.2:1.0/host6/scsi_host/host6
E: UDEV_LOG=3
E: DEVPATH=/devices/pci0000:00/0000:00:1d.7/usb1/1-2/1-2.2/1-2.2:1.0/host6/scsi_host/host6
E: SUBSYSTEM=scsi_host

P: /devices/pci0000:00/0000:00:1d.7/usb1/1-2/1-2.2/1-2.2:1.0/host6/target6:0:0
E: UDEV_LOG=3
E: DEVPATH=/devices/pci0000:00/0000:00:1d.7/usb1/1-2/1-2.2/1-2.2:1.0/host6/target6:0:0
E: DEVTYPE=scsi_target
E: SUBSYSTEM=scsi

P: /devices/pci0000:00/0000:00:1d.7/usb1/1-2/1-2.2/1-2.2:1.0/host6/target6:0:0/6:0:0:0
E: UDEV_LOG=3
E: DEVPATH=/devices/pci0000:00/0000:00:1d.7/usb1/1-2/1-2.2/1-2.2:1.0/host6/target6:0:0/6:0:0:0
E: DEVTYPE=scsi_device
E: DRIVER=sd
E: MODALIAS=scsi:t-0x00
E: SUBSYSTEM=scsi

P: /devices/pci0000:00/0000:00:1d.7/usb1/1-2/1-2.2/1-2.2:1.0/host6/target6:0:0/6:0:0:0/block/sdc
N: sdc
S: disk/by-id/usb-OLYMPUS_C-4040ZOOM_000197314779-0:0
S: disk/by-path/pci-0000:00:1d.7-usb-0:2.2:1.0-scsi-0:0:0:0
E: UDEV_LOG=3
E: DEVPATH=/devices/pci0000:00/0000:00:1d.7/usb1/1-2/1-2.2/1-2.2:1.0/host6/target6:0:0/6:0:0:0/block/sdc
E: MAJOR=8
E: MINOR=32
E: DEVNAME=/dev/sdc
E: DEVTYPE=disk
E: SUBSYSTEM=block
E: ID_VENDOR=OLYMPUS
E: ID_VENDOR_ENC=OLYMPUS\x20
E: ID_VENDOR_ID=07b4
E: ID_MODEL=C-4040ZOOM
E: ID_MODEL_ENC=C-4040ZOOM\x20\x20\x20\x20\x20\x20
E: ID_MODEL_ID=0105
E: ID_REVISION=1.00
E: ID_SERIAL=OLYMPUS_C-4040ZOOM_000197314779-0:0
E: ID_SERIAL_SHORT=000197314779
E: ID_TYPE=disk
E: ID_INSTANCE=0:0
E: ID_BUS=usb
E: ID_USB_INTERFACES=:080650:
E: ID_USB_INTERFACE_NUM=00
E: ID_USB_DRIVER=usb-storage
E: ID_PATH=pci-0000:00:1d.7-usb-0:2.2:1.0-scsi-0:0:0:0
E: UDISKS_PRESENTATION_NOPOLICY=0
E: DEVLINKS=/dev/disk/by-id/usb-OLYMPUS_C-4040ZOOM_000197314779-0:0 /dev/disk/by-path/pci-0000:00:1d.7-usb-0:2.2:1.0-scsi-0:0:0:0

P: /devices/pci0000:00/0000:00:1d.7/usb1/1-2/1-2.2/1-2.2:1.0/host6/target6:0:0/6:0:0:0/bsg/6:0:0:0
N: bsg/6:0:0:0
E: UDEV_LOG=3
E: DEVPATH=/devices/pci0000:00/0000:00:1d.7/usb1/1-2/1-2.2/1-2.2:1.0/host6/target6:0:0/6:0:0:0/bsg/6:0:0:0
E: MAJOR=253
E: MINOR=3
E: DEVNAME=/dev/bsg/6:0:0:0
E: SUBSYSTEM=bsg

P: /devices/pci0000:00/0000:00:1d.7/usb1/1-2/1-2.2/1-2.2:1.0/host6/target6:0:0/6:0:0:0/scsi_device/6:0:0:0
E: UDEV_LOG=3
E: DEVPATH=/devices/pci0000:00/0000:00:1d.7/usb1/1-2/1-2.2/1-2.2:1.0/host6/target6:0:0/6:0:0:0/scsi_device/6:0:0:0
E: SUBSYSTEM=scsi_device

P: /devices/pci0000:00/0000:00:1d.7/usb1/1-2/1-2.2/1-2.2:1.0/host6/target6:0:0/6:0:0:0/scsi_disk/6:0:0:0
E: UDEV_LOG=3
E: DEVPATH=/devices/pci0000:00/0000:00:1d.7/usb1/1-2/1-2.2/1-2.2:1.0/host6/target6:0:0/6:0:0:0/scsi_disk/6:0:0:0
E: SUBSYSTEM=scsi_disk

P: /devices/pci0000:00/0000:00:1d.7/usb1/1-2/1-2.2/1-2.2:1.0/host6/target6:0:0/6:0:0:0/scsi_generic/sg3
N: sg3
E: UDEV_LOG=3
E: DEVPATH=/devices/pci0000:00/0000:00:1d.7/usb1/1-2/1-2.2/1-2.2:1.0/host6/target6:0:0/6:0:0:0/scsi_generic/sg3
E: MAJOR=21
E: MINOR=3
E: DEVNAME=/dev/sg3
E: SUBSYSTEM=scsi_generic

P: /devices/pci0000:00/0000:00:1d.7/usb1/1-2/1-2:1.0
E: UDEV_LOG=3
E: DEVPATH=/devices/pci0000:00/0000:00:1d.7/usb1/1-2/1-2:1.0
E: DEVTYPE=usb_interface
E: DRIVER=hub
E: DEVICE=/proc/bus/usb/001/007
E: PRODUCT=1a40/101/111
E: TYPE=9/0/1
E: INTERFACE=9/0/0
E: MODALIAS=usb:v1A40p0101d0111dc09dsc00dp01ic09isc00ip00
E: SUBSYSTEM=usb
Comment 5 Marja Van Waes 2011-12-26 09:12:46 CET 
(In reply to comment #3)
> Yup, it's probably udev, especially as this is a USB Mass storage rather than
> PTP.
> 
> Can you attach the relevant bit from:
> udevadm info --export-db

@ Colin

the output is in comment 4, do you mind looking at it? I wish I could tell which line is relevant, but I can't. If you happen to be in a strong "explain-to-dummies" mood, I'd welcome some explanation ;)

Thx btw, for the other day when you were so fast to find the cause of bug 3797 and thx for the explaining you did there :)

Source RPM: libgphoto2-2.4.10.1-1.mga1 => udev-166-5.mga1.src.rpm

Comment 6 Colin Guthrie 2011-12-28 21:04:59 CET 
Hiya,

OK, so I'm not really a udev expert but I know roughly where to start poking and usually I can find something out from there... I'll try and outline the process I go through..

So I "cd /lib/udev/rules.d/" and then "grep ACL *.rules"

I then pick out a few particular rules that might write ACLs for me.

The first is 70-acl.rules, and while it talks about PTP cameras, it doesn't seem to mention anything about USB mass storage stuff.

However, I notice that is compares ID_USB_INTERFACES value.

The value from the debug output above is "ID_USB_INTERFACES=:080650:"

Looking at the rules that may match this (grep ID_USB_INTERFACES *.rules) and I come across 40-libgphoto2.rules. However this file is basically just saying: "if it matches 08*, then only check a few basic things". So basically we do nothing. However, looking in that file, I can find the vendor/device id there... it's inside the section that is skipped due to matching 08* on ID_USB_INTERFACES).

What's curious is that it's mentioned several times:
[colin@marley rules.d]$ grep 07b4.*0105 *.rules
40-libgphoto2.rules:ATTRS{idVendor}=="07b4", ATTRS{idProduct}=="0105", ENV{ID_GPHOTO2}="1", ENV{GPHOTO2_DRIVER}="proprietary"
40-libgphoto2.rules:ATTRS{idVendor}=="07b4", ATTRS{idProduct}=="0105", ENV{ID_GPHOTO2}="1", ENV{GPHOTO2_DRIVER}="proprietary"
40-libgphoto2.rules:ATTRS{idVendor}=="07b4", ATTRS{idProduct}=="0105", ENV{ID_GPHOTO2}="1", ENV{GPHOTO2_DRIVER}="proprietary"
40-libgphoto2.rules:ATTRS{idVendor}=="07b4", ATTRS{idProduct}=="0105", ENV{ID_GPHOTO2}="1", ENV{GPHOTO2_DRIVER}="proprietary"
40-libgphoto2.rules:ATTRS{idVendor}=="07b4", ATTRS{idProduct}=="0105", ENV{ID_GPHOTO2}="1", ENV{GPHOTO2_DRIVER}="proprietary"
40-libgphoto2.rules:ATTRS{idVendor}=="07b4", ATTRS{idProduct}=="0105", ENV{ID_GPHOTO2}="1", ENV{GPHOTO2_DRIVER}="proprietary"
40-libgphoto2.rules:ATTRS{idVendor}=="07b4", ATTRS{idProduct}=="0105", ENV{ID_GPHOTO2}="1", ENV{GPHOTO2_DRIVER}="proprietary"
40-libgphoto2.rules:ATTRS{idVendor}=="07b4", ATTRS{idProduct}=="0105", ENV{ID_GPHOTO2}="1", ENV{GPHOTO2_DRIVER}="proprietary"


All these lines seem to be the same to me which is odd to say the least.

However, when considering these lines are completely gone in the newer udev in Cauldron, perhaps it's not something to worry about.


OK, so nothing so far.

So perhaps something else is at play here?

Lets look at how USB mass storage is handled generally.

Even in cauldron if I plug in a USB flash drive, I get /dev/sdb* nodes, which are owned by root:disk and have no ACLs on them, but I can still mount them in GNOME and KDE... so really the permissions thing is perhaps a red-herring.

I guess a bigger question is what applications and desktop environment are you using and how are you trying to mount the drive?
Comment 7 Herbert Poetzl 2012-02-15 21:18:14 CET 
(In reply to comment #6)

> Even in cauldron if I plug in a USB flash drive, I get /dev/sdb* nodes, which
> are owned by root:disk and have no ACLs on them, but I can still mount them in
> GNOME and KDE... so really the permissions thing is perhaps a red-herring.

maybe, but note that gphoto2 explicitely says that it "doesn't have permission" to access the device" and changing that permission makes at least gphoto2 work.
 
> I guess a bigger question is what applications and desktop environment are you
> using and how are you trying to mount the drive?

I'm not trying to "mount the device", I'm trying to "import photos", and while that worked fine before Mageia, it gets worse and worse (see Bug 2937 and Bug 4264)
Comment 8 Marja Van Waes 2012-04-23 17:10:42 CEST 
(In reply to comment #7)
> (In reply to comment #6)
> 
> > Even in cauldron if I plug in a USB flash drive, I get /dev/sdb* nodes, which
> > are owned by root:disk and have no ACLs on them, but I can still mount them in
> > GNOME and KDE... so really the permissions thing is perhaps a red-herring.
> 
> maybe, but note that gphoto2 explicitely says that it "doesn't have permission"
> to access the device" and changing that permission makes at least gphoto2 work.
> 
> > I guess a bigger question is what applications and desktop environment are you
> > using and how are you trying to mount the drive?
> 
> I'm not trying to "mount the device", I'm trying to "import photos", and while
> that worked fine before Mageia, it gets worse and worse (see Bug 2937 and Bug
> 4264)



And which DE are you using?
Comment 9 Herbert Poetzl 2012-04-23 21:26:56 CEST 
Gnome3 (gnome-shell), systemd, latest Cauldron

CC: (none) => herbert

Marja Van Waes 2012-05-06 16:43:31 CEST

Blocks: (none) => 2937

Comment 10 Manuel Hiebel 2012-11-05 16:52:42 CET 
This message is a reminder that Mageia 1 is nearing its end of life. 
In approximately 25 days from now, Mageia will stop maintaining and issuing 
updates for Mageia 1. At that time this bug will be closed as WONTFIX (EOL) if it 
remains open with a Mageia 'version' of '1'.

Package Maintainer: If you wish for this bug to remain open because you plan to 
fix it in a currently maintained version, simply change the 'version' to a later 
Mageia version prior to Mageia 1's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that we may not 
be able to fix it before Mageia 1 is end of life.  If you would still like to see 
this bug fixed and are able to reproduce it against a later version of Mageia, 
you are encouraged to click on "Version" and change it against that version 
of Mageia.

Although we aim to fix as many bugs as possible during every release's lifetime, 
sometimes those efforts are overtaken by events. Often a more recent Mageia 
release includes newer upstream software that fixes bugs or makes them obsolete.

--
Mageia Bugsquad
Comment 11 Manuel Hiebel 2012-12-02 14:32:10 CET 
Mageia 1 changed to end-of-life (EOL) status on ''1st December''. Mageia 1 is no 
longer maintained, which means that it will not receive any further security or 
bug fix updates. As a result we are closing this bug. 

If you can reproduce this bug against a currently maintained version of Mageia 
please feel free to click on "Version" change it against that version of Mageia and reopen this bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

--
Mageia Bugsquad

Status: NEW => RESOLVED
Resolution: (none) => WONTFIX
Note You need to log in before you can comment on or make changes to this bug.