Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 177650 - USB scanner device not available to console user.
USB scanner device not available to console user.
Product: Fedora
Classification: Fedora
Component: hotplug (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Bill Nottingham
Brock Organ
: 121511 (view as bug list)
Depends On: 178994
  Show dependency treegraph
Reported: 2006-01-12 12:30 EST by David Woodhouse
Modified: 2014-03-16 22:57 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-01-27 13:26:27 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
udev rules file (27.67 KB, text/plain)
2006-01-18 00:23 EST, Bill Nottingham
no flags Details
patched libsusb (372.49 KB, application/octet-stream)
2006-01-18 00:23 EST, Bill Nottingham
no flags Details
new rules file (26.88 KB, text/plain)
2006-01-25 15:57 EST, Bill Nottingham
no flags Details

  None (edit)
Description David Woodhouse 2006-01-12 12:30:53 EST
I have a USB scanner:

Bus 004 Device 014: ID 03f0:0401 Hewlett-Packard ScanJet 5200c

Under FC4, the magic file in /proc/bus/usb (which isn't actually a device node)
was automatically chowned so that the console user could access it, and xsane
would work. Under FC5t2, this doesn't happen -- I cannot use xsane as myself. It
works (with appropriate warnings) when run as root though.
Comment 1 Bill Nottingham 2006-01-12 14:16:49 EST
Are the devices still under /proc/bus/usb used?

ISTR reading that Something Else was supposed to be done, in conjunction with
udev. Lemme see if I can dig up the ref.
Comment 2 Bill Nottingham 2006-01-12 14:21:18 EST

Comment 3 David Woodhouse 2006-01-12 14:34:54 EST
Yes. Running xsane as root and then looking at the file descriptors it has open
shows that it's using /proc/bus/usb/004/014
Comment 4 Bill Nottingham 2006-01-18 00:22:31 EST
OK, here's some stuff to test. Please:

a) install the attached udev rules file in /etc/udev/rules.d
b) rebuild the attached libusb, and install it
c) *unmount* /proc/bus/usb
d) reconnect your scanner

Then please report:
1) does sane use the device nodes in /dev/ instead of /proc?
2) does udev create /dev/scanner-XXX devices
3) does this cause pam_console to chmod the /dev usb devices to the right owner?
4) does the right thing happen on disconnect?

Sorry, I don't have hardware to test this with. :/
Comment 5 Bill Nottingham 2006-01-18 00:23:16 EST
Created attachment 123351 [details]
udev rules file
Comment 6 Bill Nottingham 2006-01-18 00:23:59 EST
Created attachment 123352 [details]
patched libsusb
Comment 7 Bill Nottingham 2006-01-18 00:32:22 EST
CCing Nils and Tim - if this works, we need this for FC5. Should solve 121511 as
well. Basically, this makes libusb use the device nodes that udev creates,
rather than the stuff in usbdevfs, and adds udev rules for the scanners
(formerly in the usermap) to create scanner symlinks that pam_console will then

The udev rules was simply done with:

cat libsane.usermap | awk '{ print $3 $4 }' | while read v d ; do
  echo ".... SYSFS{vendor}=$v, SYSFS{device}=$d, ...."

This should be easily scriptable in the spec, at least. (There's some other
stuff in core/extras that probably needs this too.)

However, I don't have any hardware to test this with. More eyes/guinea pigs
needed. :)
Comment 8 David Woodhouse 2006-01-18 02:36:10 EST
I'm not going to be back home where the hardware is until February, but I'll
test it then if nobody's done so beforehand.
Comment 9 Tim Waugh 2006-01-18 04:15:49 EST
Adding new libusb maintainer to CC.
Comment 10 Bill Nottingham 2006-01-18 11:10:45 EST
*** Bug 121511 has been marked as a duplicate of this bug. ***
Comment 11 Ian Pilcher 2006-01-19 13:22:08 EST
I have tried the steps in comment #4, with no success.  The /dev/scanner-XXX
nodes are not created.  IIRC from the days of bug #121511, udev rules can't
help, because libusb devices don't create a udev event.

Note also that any solution much cover two different scenarios -- cold-
plugging (or hotplugging when no console user is logged in) and hotplugging
when a console user is logged in.  In the second scenario, I believe that
pam_console won't normally get called.  Once upon a time, one of the USB
hotplug scripts automatically set the permissions to the current console
user, if there was one.  While this worked, it meant that the ownership
policy for USB scanners was stored in two places (and was hardcoded in one
of them).  Needless to say, this is bad.
Comment 12 Bill Nottingham 2006-01-19 14:18:04 EST
(In reply to comment #11)
> I have tried the steps in comment #4, with no success.  The /dev/scanner-XXX
> nodes are not created.  IIRC from the days of bug #121511, udev rules can't
> help, because libusb devices don't create a udev event.

That's what this is intended to fix - moving to actual, udev-created, devices.
The scanner-XXX stuff is just symlinks so pam_console works.

If you run udevmonitor before attaching the scanner, what output does it print
on attach?

> Note also that any solution much cover two different scenarios -- cold-
> plugging (or hotplugging when no console user is logged in) and hotplugging
> when a console user is logged in.  In the second scenario, I believe that
> pam_console won't normally get called.

This *should* solve that (when it works), as when you hotplug, udev will create
the device nodes/symlinks, and then check them with pam_console.
Comment 13 Ian Pilcher 2006-01-19 20:19:56 EST
Here is the output from udevmonitor (plug & unplug):

UEVENT[1137719855.369193] add@/devices/pci0000:00/0000:00:1d.1/usb2/2-2
UEVENT[1137719855.369282] add@/devices/pci0000:00/0000:00:1d.1/usb2/2-2/2-2:1.0
UEVENT[1137719855.369317] add@/class/usb_device/usbdev2.3
UDEV  [1137719855.372659] add@/devices/pci0000:00/0000:00:1d.1/usb2/2-2
UDEV  [1137719855.479858] add@/devices/pci0000:00/0000:00:1d.1/usb2/2-2/2-2:1.0
UDEV  [1137719855.591790] add@/class/usb_device/usbdev2.3

UEVENT[1137719878.674995] remove@/devices/pci0000:00/0000:00:1d.1/usb2/2-2/2-2:1.0
UEVENT[1137719878.675597] remove@/class/usb_device/usbdev2.3
UEVENT[1137719878.675629] remove@/devices/pci0000:00/0000:00:1d.1/usb2/2-2
UDEV  [1137719878.676949] remove@/devices/pci0000:00/0000:00:1d.1/usb2/2-2/2-2:1.0
UDEV  [1137719878.701976] remove@/class/usb_device/usbdev2.3
UDEV  [1137719878.724143] remove@/devices/pci0000:00/0000:00:1d.1/usb2/2-2

Definitely no /dev entries, though.
Comment 14 Bill Nottingham 2006-01-20 13:11:18 EST
Oh, hm. I suspect what's happening is that when it's triggering on the
/class/usb_device/usbdevXX devices, the vendor and device id files aren't in
that directory.
Comment 15 Bill Nottingham 2006-01-20 13:12:29 EST
Oops. What happens if you do s/vendor/idVendor/ and s/device/idProduct/ to the
rules file?
Comment 16 Ian Pilcher 2006-01-20 15:06:29 EST
I think you want 's/{device}/{idProduct}/'.  Otherwise, it catches the
'SUBSYSTEM=="usb_device"' portion of each line.

So my rules file now has lines which look like:

ACTION=="add", SUBSYSTEM=="usb_device", SYSFS{idVendor}==0x03f0,
SYSFS{idProduct}==0x0405, SYMLINK+="scanner-usb-%k"

The output from udevmonitor is the same as above (except that it's usbdev2.2
this time, probably because it was the first time I plugged in the scanner
since rebooting).

I did notice, however, that a device node /dev/usbdev2.2 appeared when I
plugged the scanner in and disappeared when I unplugged it.  I honestly
don't know if that happened previously, since I was only looking for
/dev/scanner-XXX entries.

BTW, I have verified that my scanner (04b8:0110) is listed.
Comment 17 Bill Nottingham 2006-01-20 15:56:29 EST
Sorry, I hate to do this back-and-forth debugging like this, but what happens if
you change it from:

 SYSFS{idVendor} ... SYSFS{idProduct}


 SYSFS{device/idVendor} ... SYSFS{device/idProduct}

Comment 18 Ian Pilcher 2006-01-20 16:23:49 EST
Same result.  Looking at the output of udevmon --env, it looks like the rule
might work (with SYSFS{idVendor} and SYSFS{idProduct}) if the SUBSYSTEM were
specified as "usb", rather than "usb_device".  In this case, DEVICE points to
the /proc/bus/usb... file, but that would work with an unpatched libusb,
wouldn't it?
Comment 19 Bill Nottingham 2006-01-20 16:29:09 EST
Not really, because we don't want to rely on usbdevfs.
Comment 20 Ian Pilcher 2006-01-20 17:01:18 EST
In that case, if I'm correct than SYSFS rules won't work with relative paths
like that, I think that you're going to need a helper program.
Comment 21 Bill Nottingham 2006-01-20 17:26:47 EST
Well, we have rules in the current config with relative paths, so I sort of
assumed they *did* work. I should check that. :)
Comment 22 Jindrich Novy 2006-01-22 08:45:34 EST
New libusb-0.1.11 is now built in rawhide btw. Not sure whether it helps here
somehow though.
Comment 23 Jim Cornette 2006-01-24 14:34:00 EST
Not using my scanner since bug 121511 seemed to fix the operation of the scanner
to work with the console user, I will try the scanner with present FC5T2 on a
different computer.
Hardware: HP ScanJet 2100C
Adding to self CC:
Comment 24 Bill Nottingham 2006-01-25 15:57:39 EST
Created attachment 123688 [details]
new rules file

This rules file (in conjunction with the patched libusb) should fix it. I'll
build a new sane-backends.
Comment 25 Linus Walleij 2006-01-25 16:25:07 EST
Since scanners also use libusb and also use /dev/bus/usb they will have
the problem found in bug 178543, and need the first part of the patch
I did against libusb (to support [0-9A-F]+ device node names) to work 
properly as of now. (I think.)

Bill, can you get this and the other patch into the libusb-0.1.11 at
rawhide so we have a working system until upstream indicate how we shall
solve it?
Comment 26 Jindrich Novy 2006-01-25 16:40:57 EST
Linus, could you file a separate bug against libusb with the required patches
and add a reference to it here?
Comment 27 Linus Walleij 2006-01-26 03:46:34 EST
Well I sent a mail off to both libusb-devel and linux-hotplug-devel
to have the situation sorted out. Let us see what they say.
Comment 28 Linus Walleij 2006-01-26 03:51:54 EST
Kay has cleared things up on libusb-devel and linux-hotplug-devel.
Device nodes in /dev/bus/usb shall be named exactly as in /proc/bus/usb
the Fedora udev rule creating the nodes was erroneous.

Bug identified in Fedora udev package, Harald Hoyer has fixed it. 

No changes should be needed in libusb. 

Waiting for confirmation that the bug is gone...
Comment 29 Linus Walleij 2006-01-26 05:16:31 EST
The resolution of this bug depends on bug 178994.
The modified RPM by Bill has this fix...
Comment 30 Bill Nottingham 2006-01-27 13:26:27 EST
Should be fixed with current rawhide libusb (0.1.11-2), sane-backends
(1.0.17-3), and udev (078-8).
Comment 31 David Woodhouse 2006-02-07 04:58:32 EST
Yeah, this works again on a clean rawhide-20060206 install. Well, it works with
the 'hp' sane backend. The 'hpaio' backend segfaults but at least it doesn't do
it at _probe_ time; only if I make the mistake of using it. qv. 
Comment 32 Tim Waugh 2006-02-07 05:01:08 EST
dwmw2: please file an HPLIP bug for the hpaio backend segfault.  Thanks.
Comment 33 David Woodhouse 2006-02-07 05:06:57 EST
I think I already filed it, although against sane. Hence the 'qv'.
Comment 34 Nils Philippsen 2006-02-13 08:14:00 EST
I've to admit my ignorance: what does 'qv' mean?
Comment 35 David Woodhouse 2006-02-13 11:45:11 EST
It's used in dictionaries etc. to indicate that whatever is being discussed has
a separate entry of its own. I believe it's from the latin 'quod vide' (see which).
Comment 36 David Woodhouse 2006-03-07 10:53:21 EST
fails on rawhide-20060307, and even root cannot find the HP device any more.
Possibly not the same problem?
Comment 37 Bill Nottingham 2006-03-07 11:59:38 EST
Possibly not. Is it seen with lsusb, etc? Do the devices exist under /dev/bus/usb?

Is libusb actually trying to look at them (check with strace, etc.)

Note You need to log in before you can comment on or make changes to this bug.