Regression: 1394 scanner device (sgN) permissions

Bug #662065 reported by David Meier on 2010-10-17
18
This bug affects 3 people
Affects Status Importance Assigned to Milestone
udev (Ubuntu)
Undecided
Unassigned

Bug Description

Binary package hint: udev

I used a 1394 scanner (Nikon 8000) successfully until karmic. After upgrading to maverick however, the device is only accessible to root:

$ ls -l /dev/sg4
crw------- 1 root root 21, 4 2010-10-17 12:02 /dev/sg4

Granting rw-permissions to "other" fixes the problem.
More sensible permissions should be the default.

This is what udev knows about the device:

$ udevadm info -a -rp /sys/class/scsi_generic/sg4

Udevadm info starts with the device specified by the devpath and then
walks up the chain of parent devices. It prints for every device
found, all possible attributes in the udev rules key format.
A rule to match, can be composed by the attributes of the device
and the attributes from one single parent device.

  looking at device '/devices/pci0000:00/0000:00:06.0/0000:01:0b.0/fw1/fw1.0/host10/target10:0:0/10:0:0:0/scsi_generic/sg4':
    KERNEL=="sg4"
    SUBSYSTEM=="scsi_generic"
    DRIVER==""

  looking at parent device '/devices/pci0000:00/0000:00:06.0/0000:01:0b.0/fw1/fw1.0/host10/target10:0:0/10:0:0:0':
    KERNELS=="10:0:0:0"
    SUBSYSTEMS=="scsi"
    DRIVERS==""
    ATTRS{device_blocked}=="0"
    ATTRS{type}=="6"
    ATTRS{scsi_level}=="3"
    ATTRS{vendor}=="Nikon "
    ATTRS{model}=="LS-8000 ED "
    ATTRS{rev}=="1.11"
    ATTRS{state}=="running"
    ATTRS{timeout}=="0"
    ATTRS{iocounterbits}=="32"
    ATTRS{iorequest_cnt}=="0x1"
    ATTRS{iodone_cnt}=="0x1"
    ATTRS{ioerr_cnt}=="0x0"
    ATTRS{modalias}=="scsi:t-0x06"
    ATTRS{evt_media_change}=="0"
    ATTRS{dh_state}=="detached"
    ATTRS{queue_depth}=="1"
    ATTRS{queue_type}=="none"
    ATTRS{ieee1394_id}=="0090b54002ffffff:00042c:0000"

  looking at parent device '/devices/pci0000:00/0000:00:06.0/0000:01:0b.0/fw1/fw1.0/host10/target10:0:0':
    KERNELS=="target10:0:0"
    SUBSYSTEMS=="scsi"
    DRIVERS==""

  looking at parent device '/devices/pci0000:00/0000:00:06.0/0000:01:0b.0/fw1/fw1.0/host10':
    KERNELS=="host10"
    SUBSYSTEMS=="scsi"
    DRIVERS==""

  looking at parent device '/devices/pci0000:00/0000:00:06.0/0000:01:0b.0/fw1/fw1.0':
    KERNELS=="fw1.0"
    SUBSYSTEMS=="firewire"
    DRIVERS=="sbp2"
    ATTRS{modalias}=="ieee1394:ven000090B5mo00004002sp0000609Ever00010483"
    ATTRS{rom_index}=="11"
    ATTRS{specifier_id}=="0x00609e"
    ATTRS{version}=="0x010483"
    ATTRS{model}=="0x004002"
    ATTRS{model_name}=="LS-8000 ED"

  looking at parent device '/devices/pci0000:00/0000:00:06.0/0000:01:0b.0/fw1':
    KERNELS=="fw1"
    SUBSYSTEMS=="firewire"
    DRIVERS==""
    ATTRS{guid}=="0x0090b54002ffffff"
    ATTRS{units}=="0x00609e:0x010483"
    ATTRS{vendor}=="0x0090b5"
    ATTRS{hardware_version}=="0x00500a"
    ATTRS{vendor_name}=="Nikon"

  looking at parent device '/devices/pci0000:00/0000:00:06.0/0000:01:0b.0':
    KERNELS=="0000:01:0b.0"
    SUBSYSTEMS=="pci"
    DRIVERS=="firewire_ohci"
    ATTRS{vendor}=="0x104c"
    ATTRS{device}=="0x8023"
    ATTRS{subsystem_vendor}=="0x1043"
    ATTRS{subsystem_device}=="0x808b"
    ATTRS{class}=="0x0c0010"
    ATTRS{irq}=="19"
    ATTRS{local_cpus}=="00000000,00000003"
    ATTRS{local_cpulist}=="0-1"
    ATTRS{modalias}=="pci:v0000104Cd00008023sv00001043sd0000808Bbc0Csc00i10"
    ATTRS{numa_node}=="0"
    ATTRS{dma_mask_bits}=="32"
    ATTRS{consistent_dma_mask_bits}=="32"
    ATTRS{enable}=="1"
    ATTRS{broken_parity_status}=="0"
    ATTRS{msi_bus}==""

  looking at parent device '/devices/pci0000:00/0000:00:06.0':
    KERNELS=="0000:00:06.0"
    SUBSYSTEMS=="pci"
    DRIVERS==""
    ATTRS{vendor}=="0x10de"
    ATTRS{device}=="0x0370"
    ATTRS{subsystem_vendor}=="0x10de"
    ATTRS{subsystem_device}=="0xcb84"
    ATTRS{class}=="0x060401"
    ATTRS{irq}=="0"
    ATTRS{local_cpus}=="00000000,00000003"
    ATTRS{local_cpulist}=="0-1"
    ATTRS{modalias}=="pci:v000010DEd00000370sv000010DEsd0000CB84bc06sc04i01"
    ATTRS{numa_node}=="0"
    ATTRS{dma_mask_bits}=="32"
    ATTRS{consistent_dma_mask_bits}=="32"
    ATTRS{enable}=="1"
    ATTRS{broken_parity_status}=="0"
    ATTRS{msi_bus}=="1"

  looking at parent device '/devices/pci0000:00':
    KERNELS=="pci0000:00"
    SUBSYSTEMS==""
    DRIVERS==""

Ok. The same regression here with an Epson scanner. It's dual interface and Just Works if plugged in as a USB device but the permissions for the device need changing from root to work on firewire.

I've run the same diagnostic as above, but can't see where in it the user and group are set. For now I can manually reset owner and group to use the Firewire interface, but where should it be set automatically?

Some googling and thinking later, I have now added an ad hoc udev rule which sorts it for me for now.

/etc/udev/rules.d/90-scannerbodge.rules

SUBSYSTEMS=="scsi",ATTRS{vendor}=="EPSON ",MODE="0666"

This is far from foolproof or good practice but as I have no other Epson devices at the moment, and am unlikely to have any on the scsi subsystem it suffices as proof of concept and works round the problem for now.

I'd still be interested to know where the rule should be by default, as I've no doubt it should be somewhere else than where I've put it.

John Sauter (john-sauter) wrote :

I am seeing this same symptom with an Epson Perfection V700 photo.

Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in udev (Ubuntu):
status: New → Confirmed
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers