Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!

Full Text Bug Listing

emerging libusb-0.1.12 causes the famous "can't scan as non-root" permissions
problem. Reversion to libusb-0.1.11 fixes the problem.

Same problem here, not only for scanning, I can't access my digital camera
either!

This is what I get with libusb-0.1.12 (as root):
hardcore ~ # sane-find-scanner 

found USB scanner (vendor=0x06b9 [ALCATEL], product=0x4061 [Speed Touch USB ])
at libusb:002:003
  # Your USB scanner was (probably) detected. It may or may not be supported by
  # SANE. Try scanimage -L and read the backend's manpage.

hardcore ~ # scanimage -L
device `plustek:libusb:002:004' is a Canon N670U/N676U/LiDE20 USB flatbed
scanner

when I try to access my usb-scanner as a normal user:

tekknokaetzi@hardcore ~ $ sane-find-scanner

found USB scanner (vendor=0x04a9, product=0x220d, chip=LM983x?) at
libusb:002:004
found USB scanner (vendor=0x06b9, product=0x4061) at libusb:002:003
  # Your USB scanner was (probably) detected. It may or may not be supported by
  # SANE. Try scanimage -L and read the backend's manpage.

tekknokaetzi@hardcore ~ $ scanimage -L

No scanners were identified. If you were expecting something different,
check that the scanner is plugged in, turned on and detected by the
sane-find-scanner tool (if appropriate). Please read the documentation
which came with this software (README, FAQ, manpages).

Same problem for my digital camera: it's recognised but I can't access it.

after reverting back to libusb-0.1.11 I can access my scanner and my digital
camera as a normal user:

tekknokaetzi@hardcore ~ $ sane-find-scanner

found USB scanner (vendor=0x04a9 [Canon], product=0x220d [CanoScan],
chip=LM9832/3) at libusb:002:005
  # Your USB scanner was (probably) detected. It may or may not be supported by
  # SANE. Try scanimage -L and read the backend's manpage.

tekknokaetzi@hardcore ~ $ scanimage -L
device `plustek:libusb:002:005' is a Canon N670U/N676U/LiDE20 USB flatbed
scanner

emerge --info:
Portage 2.1_pre9-r5 (default-linux/x86/2005.0, gcc-4.0.3, glibc-2.3.6-r3,
2.6.16-beyond-git12 i686)
=================================================================
System uname: 2.6.16-beyond-git12 i686 Intel(R) Pentium(R) 4 CPU 1400MHz
Gentoo Base System version 1.12.0_pre18
ccache version 2.4 [enabled]
dev-lang/python:     2.4.2-r1
dev-util/ccache:     2.4-r1
dev-util/confcache:  [Not Present]
sys-apps/sandbox:    1.2.17
sys-devel/autoconf:  2.13, 2.59-r7
sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2
sys-devel/binutils:  2.16.1-r2
sys-devel/libtool:   1.5.22
virtual/os-headers:  2.6.11-r5
ACCEPT_KEYWORDS="x86 ~x86"
AUTOCLEAN="yes"
CBUILD="i686-pc-linux-gnu"
CFLAGS="-march=pentium4 -mtune=pentium4 -msse -msse2 -pipe -O2
-fomit-frame-pointer -momit-leaf-frame-pointer -fno-ident -fforce-addr
-falign-functions=4"
CHOST="i686-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.5/env
/usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/kde/3/share/config
/usr/share/X11/xkb /usr/share/config /var/qmail/control"
CONFIG_PROTECT_MASK="/etc/eselect/compiler /etc/gconf /etc/revdep-rebuild
/etc/terminfo /etc/env.d"
CXXFLAGS="-march=pentium4 -mtune=pentium4 -msse -msse2 -pipe -O2
-fomit-frame-pointer -momit-leaf-frame-pointer -fno-ident -fforce-addr
-falign-functions=4 -fvisibility-inlines-hidden"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoconfig ccache distlocks metadata-transfer sandbox sfperms strict"
GENTOO_MIRRORS="ftp://sunsite.informatik.rwth-aachen.de/pub/Linux/gentoo
ftp://linux.rz.ruhr-uni-bochum.de/gentoo-mirror
http://mirrors.sec.informatik.tu-darmstadt.de/gentoo/
ftp://ftp-stud.fht-esslingen.de/pub/Mirrors/gentoo/
ftp://gentoo.inode.at/source/ http://gentoo.oregonstate.edu
http://www.ibiblio.org/pub/Linux/distributions/gentoo"
LANG="de_DE@euro"
LC_ALL="de_DE@euro"
LDFLAGS="-Wl,-O1 -Wl,--enable-new-dtags -Wl,--sort-common -s -Wl,--as-needed"
LINGUAS="de"
MAKEOPTS="-j2"
PKGDIR="/usr/portage/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/local/portage /usr/local/overlays/gentoo-de"
SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage"
USE="x86 X acpi alsa arts atm avi bitmap-fonts cdr cli crypt cups divx4linux
dlloader dri dvd encode ffmpeg foomaticdb gdbm gif gphoto2 gpm gtk gtk2 imlib
ipv6 isdnlog joystick jpeg kde libg++ libwww mad mmx motif mp3 mpeg ncurses nls
nptl nptlonly nsplugin nvidia ogg oggvorbis opengl oss pam pcre pdf pdflib perl
pic png pppd python qt quicktime readline real reflection scanner sdl session
spell spl sse sse2 ssl svga tcpd tiff truetype truetype-fonts type1-fonts usb
vorbis win32codecs wmf xml2 xmms xorg xv zlib elibc_glibc
input_devices_keyboard input_devices_mouse kernel_linux linguas_de userland_GNU
video_cards_nv video_cards_nvidia video_cards_fbdev video_cards_vesa"
Unset:  ASFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK

I did some debugging. It seems that the line

ret = ioctl(dev->fd, IOCTL_USB_SETCONFIG, &configuration);

in usb_set_configuration in linux.c returns a different error as non-root for
libusb-0.1.12 and libusb-0.1.11. libusb-0.1.12 returns E_PERM.

OK, I found out why this is happening, but the answer is not pleasant. It turns
out that libusb-0.1.11 is looking for usb devices at /proc/bus/usb while
libusb-0.1.12 is looking at /dev/bus/usb.

All the documentation and hotplug scripts call for changing permissions at
/proc/bus/usb.

One solution is to change all the documentation and hotplug scripts to change
permissions at /dev/bus/usb instead.

I don't know the extent or consequences ot this change. Comments?

OK, here's how I fixed this problem. I added the file 10-scanner.rules to
/etc/udev/rules.d consisting of the line:

BUS="usb", SYSFS{idVendor}="04b8", SYSFS{idProduct}="0818", PROGRAM="/bin/sh -c
'K=%k; K=$${K#usbdev}; printf bus/usb/%%03i/%%03i $${K%%%%.*} $${K#*.}'",
NAME="%c", MODE="0660", GROUP="scanner"

Can confirm this bug with gphoto.

Changing perms on /dev/bus/usb/appropriate/file allows non-root access again.

Don't have a pretty, general solution.

http://libusb.cvs.sourceforge.net/libusb/libusb/linux.c?r1=1.77&r2=1.78

this is the change that did it. which documentation says to change the
permissions on /proc/bus/usb? on my machine both permissions are the same, no
root write access, am I missing something?

(In reply to comment #6)
> http://libusb.cvs.sourceforge.net/libusb/libusb/linux.c?r1=1.77&r2=1.78
> 
> this is the change that did it. which documentation says to change the
> permissions on /proc/bus/usb? on my machine both permissions are the same, no
> root write access, am I missing something?
> 

The code changes that you reference seem to be related to determining whether
usb is found or not, either /proc/bus/usb or /dev/bus/usb. The change that
seems to cause the problem is code determining the permissions of the usb
devices, which have changed from /proc/bus/usb to /dev/bus/usb. The permissions
are now checked on /dev/bus/usb. On your machine, are you looking at
/proc/bus/usb, /dev/bus/usb, or both?

The workaround here, and in the forums, is to write a special udev rule to
create the /dev/bus/usb devices with the proper permissions for the new usb
device. This is unsatisfactory as it is not general and depends on writing
special udev rules for each specific usb device.

I agree that the udev rules is not a good solution. I'll see if I can get
upstream to look at this.

i got the same problem, downgrading to libsusb-0.1.11 works fine for me, on
0.1.12 i couldn' acces even my camera had to do udev rule but this is not ok

vapier, you might not want to mark libusb-0.1.12 stable for sh, s390 and arm
because of this bug.

isnt udev broken ?  shouldnt this line:

SUBSYSTEM=="usb_device", PROGRAM="/bin/sh -c 'K=%k; K=$${K#usbdev}; printf
bus/usb/%%03i/%%03i $${K%%%%.*} $${K#*.}'", NAME="%c", MODE="0644"

read MODE="0664" and GROUP="usb"

The same error here. But after

  echo "=media-gfx/sane-backends-1.0.18-r2 ~x86" >>
/etc/portage/package.keywords
  emerge -pu sane-backends

  These are the packages that would be merged, in order:

  Calculating dependencies... done!
  [ebuild     U ] media-gfx/sane-backends-1.0.18-r2 [1.0.17]
  emerge -u sane-backends
  etc-update
  reboot

scanning as non-root with libusb-0.1.12 works again for me.
(According to Bug 148608 sane-backends-1.0.18-r2 should become x86 stable
soon.)

gregkh: check out Comment #11

Also encountered this issue with gphoto and a Canon camera. USB permissions
under /proc/bus/usb are correct, but apparently libusb checks them at
/dev/bus/usb.

Can 0.1.12 be marked back to testing for time being, until solution is found,
perhaps upstream?

*** Bug 149968 has been marked as a duplicate of this bug. ***

arch teams, can you please not mark 0.1.12 stable for your respective
architectures. this problem needs to be solved otherwise your users are going
to complain.

libusb-0.1.12 back to ~ppc for now; has upstream given any feedback on this
issue yet?

sane needs udev rules written. they aren't hard to do.

the move to /dev/bus/usb was reasonably announced by upstream, and other
packages have responded in kind. I've been trying to get nut-2.0.4* stable,
because it finally supports a lot of newer USB UPSes. It ships with this udev
rule file (/etc/udev/rules.d/70-nut-usbups.rules), that sane will need to
implement something like for libusb:

# udev rules for the NUT USB drivers
SUBSYSTEM!="usb_device", ACTION!="add", GOTO="nut-usbups_rules_end"
# MGE UPS SYSTEMS - usbhid-ups
SYSFS{idVendor}=="0463", SYSFS{idProduct}=="ffff", MODE="660", GROUP="nut"
SYSFS{idVendor}=="0463", SYSFS{idProduct}=="0001", MODE="660", GROUP="nut"
# APC - usbhid-ups
SYSFS{idVendor}=="051d", SYSFS{idProduct}=="0002", MODE="660", GROUP="nut"
# Powerware - bcmxcp_usb
SYSFS{idVendor}=="0592", SYSFS{idProduct}=="0002", MODE="660", GROUP="nut"
# Tripp Lite - tripplite_usb
SYSFS{idVendor}=="09ae", SYSFS{idProduct}=="0001", MODE="660", GROUP="nut"
LABEL="nut-usbups_rules_end"

Sane should have it MUCH easier than NUT however, as IIRC all scanners should
show up with a bInterfaceClass of USB_CLASS_STILL_IMAGE (6), which means you
can cover every scanner with a single udev rule.

If two or three people with USB scanners could attach tarballs of their /sys
directory, I'll gladly whip up some udev rules for you, so that libusb can move
forward, instead of backwards.

Apparently gphoto 2.2.0 also does the UDEV rules:

http://www.gphoto.org/news/

So if you want to move this to stable, gphoto 2.2 should be stabilized at the
same time.

Could libusb-0.1.12 be marked back ~amd64 also. This bit me today also. 

The only reason the scanner worked is because had a local udev rule in there
from long time ago. 

What about what SpanKY said in #11? That is already there and shouldn't it be
written that way from the getgo? :

SUBSYSTEM=="usb_device", PROGRAM="/bin/sh -c 'K=%k; K=$${K#usbdev}; printf
bus/usb/%%03i/%%03i $${K%%%%.*} $${K#*.}'", NAME="%c", MODE="0644"

read MODE="0664" and GROUP="usb"

decibelshelp: changing that rule per spanky's request is one fix. the
alternative fix like nut uses would end up with the similar result.

spanky: maybe open a new bug to gregkh to get it fixed quicker?

Hi,

I had the same problem and found on forums another work around :

# echo "export USB_DEVFS_PATH=/proc/bus/usb" >> ~/.bash_profile

Don't use that environment variable, just fix the packages to do it properly.

Okay, back to ~amd64.  (sorry, got lost in the shuffle)  Add us back when you
want it stable again...

*** Bug 150463 has been marked as a duplicate of this bug. ***

(In reply to comment #9)
> i got the same problem, downgrading to libsusb-0.1.11 works fine for me, on
> 0.1.12 i couldn' acces even my camera had to do udev rule but this is not ok
> 

Downgrading didn't help (x86). I'm still not able to acces my ZenExtra as
normal user. I did a revdep-rebuild too.

Any suggestion?

What do the different upstreams (kernel/udev/libusb/lsb) say about this?

seems /proc/bus/usb (and usbfs) is now not longer needed, as udev can provide
all of its functions from userspace, and /dev would be a more suitable
namespace for usb device nodes anyways.

If usbfs really is deprecated/scheduled for removal, we should start fixing the
udev rules now instead of waiting till a new kernel rev. breaks stuff.

just my 2

What do the different upstreams (kernel/udev/libusb/lsb) say about this?

seems /proc/bus/usb (and usbfs) is now not longer needed, as udev can provide
all of its functions from userspace, and /dev would be a more suitable
namespace for usb device nodes anyways.

If usbfs really is deprecated/scheduled for removal, we should start fixing the
udev rules now instead of waiting till a new kernel rev. breaks stuff.

just my 2¢,
/Ernst

Strange.  I have both sane-backends, gphoto2-2.2.0, and libusb-0.1.12 on amd64,
and I can find my scanner as non-root.

Of course, the scanner in /dev/bus/usb/xxx/yyy is chgrp'ed "scanner" and the
user I use (tygris) is part of the scanner group, so I don't have a permissions
problem.

Someone double-check that:  Locate your scanner, where it's plugged in as root,
and then ls -l the device in /dev/bus/usb to see if it's chgrp'ed "scanner". 
Then check to see if the non-root user is in the "scanner" group in /etc/group.

(In reply to comment #28)
> Strange.  I have both sane-backends, gphoto2-2.2.0, and libusb-0.1.12 on amd64,
> and I can find my scanner as non-root.

  That's because gphoto 2.2.0 has been made to work with the udev stuff - like
I said earlier - it should have been marked stable at the same time as
libusb-0.1.12.

(In reply to comment #28)
> Someone double-check that:  Locate your scanner, where it's plugged in as root,
> and then ls -l the device in /dev/bus/usb to see if it's chgrp'ed "scanner". 
> Then check to see if the non-root user is in the "scanner" group in /etc/group.
> 
Mine does:
/dev/bus/usb/002:
total 0
crw-r--r-- 1 root root    189, 128 Oct 15 01:28 001
crw-rw---- 1 root scanner 189, 133 Oct 15 15:10 006

and non-root user is in the scanner group

But that is only because I have a rule for the scanner. Had to write a rule a
long time back to get it working. Wasn't the case with my camera though, before
the libusb change it worked without a rule using gphoto2.

You sure you don't have a rule for the scanner that is making this work? 

(In reply to comment #29)
> That's because gphoto 2.2.0 has been made to work with the udev stuff

Hm, i have gphoto 2.2.0 and nevertheless i had to manually create an udev rule
so the usb device for my camera is created with the right group.. (it defaults
to being owned by group root)

(In reply to comment #31)
> (In reply to comment #29)
> > That's because gphoto 2.2.0 has been made to work with the udev stuff
> 
> Hm, i have gphoto 2.2.0 and nevertheless i had to manually create an udev rule
> so the usb device for my camera is created with the right group.. (it defaults
> to being owned by group root)
> 

Ah, then the package maintainer for gphoto hasnt added the stuff referred to in
http://www.gphoto.org/news/


Build system (packagers beware!)

    * You should generate HAL FDI, linux-hotplug usb.usermap, and udev rules
now via our program:

          ${libdir}/print-camera-list (hal-fdi|usb-usermap|udev-rules)
This obsoletes print-usb-usermap and print-udev-rules.
The hal FDI file should be put into:

        /usr/share/hal/fdi/information/10freedesktop/10-camera-libgphoto2.fdi

...so yes, udev rules need to be created but gphoto has the capability to do it
automatically in 2.2.0. If the gphoto ebuild does not do it, I think a new bug
should be filed.

BTW, did you update libgphoto as well when you tested the 2.2?

(In reply to comment #33)
> BTW, did you update libgphoto as well when you tested the 2.2?

Yes, it's a dependency.

Well, i did some further research now.
the udev rules from libgphoto (i've manually added them) just call the
/etc/hotplug/usb/usbcam script, however that is already called from another
source, so gentoo already had the correct rules i guess.
The usbcam script changes the group of $DEVICE to plugdev - however, $DEVICE is
always /proc/bus/usb/..., never /dev/bus/usb/...

Created an attachment (id=100235) [details]
usbcam

> 
> Well, i did some further research now.
> the udev rules from libgphoto (i've manually added them) just call the
> /etc/hotplug/usb/usbcam script, however that is already called from another
> source, so gentoo already had the correct rules i guess.
> The usbcam script changes the group of $DEVICE to plugdev - however, $DEVICE is
> always /proc/bus/usb/..., never /dev/bus/usb/...
> 

The script is called, but there is something missing. When it's called from the
hotplug agent, $DEVICE is set to /proc/bus/usb...., but when called from udev
the device path resides in $DEVNAME.
This updated /etc/hotplug/usb/usbcam script does the job.

Created an attachment (id=100236) [details]
usbcam

Removed some debug stuff I accidentally left behind.

(In reply to comment #26)
> (In reply to comment #9)
> > i got the same problem, downgrading to libsusb-0.1.11 works fine for me, on
> > 0.1.12 i couldn' acces even my camera had to do udev rule but this is not ok
> > 
> 
> Downgrading didn't help (x86). I'm still not able to acces my ZenExtra as
> normal user. I did a revdep-rebuild too.
> 
> Any suggestion?
> 

Hello,

I confirm: downgrading to libusb-0.1.11 (or even libusb-0.1.10a) also did NOT
fix the problem (x86). However, setting "USB_DEVFS_PATH=/proc/bus/usb" does
provide a temporary solution.

(In reply to comment #36)
> Created an attachment (id=100236) [edit] [details]
> usbcam

I can confirm that this works, together with gphotos udev rules which you get
by doing:

/usr/lib/libgphoto2/print-camera-list udev-rules >
/etc/udev/rules.d/libgphoto2.rules

I have libusb-0.1.12  installed and can scan with my HP 1410 as normal user.
Looks like I cannot reproduce the problem here.

(In reply to comment #0)
> emerging libusb-0.1.12 causes the famous "can't scan as non-root" permissions
> problem. Reversion to libusb-0.1.11 fixes the problem.

Running amd64, libusb-0.1.11, libgphoto2-2.1.6-r1, gphoto2-2.1.6 => non-root
user can NOT access a digital camera whereas root can.

Entries in /proc/bus/usb are 664 root:plugdev
Entries in /dev/bus/usb are 664 root:root

chmod'ing the /dev/bus/usb to 666 gives access, presumably changing the group
to plugdev would do the same.

I don't really know how to interpret the 50-udev.rules file but there is only
one entry for usb_devices that I can see.

(In reply to comment #39)
> I have libusb-0.1.12  installed and can scan with my HP 1410 as normal user.
> Looks like I cannot reproduce the problem here.
> 
With libusb-0.1.12 (x86), I can as well scan with my HP PSC 1210. However, I
cannot access my digital camera (unless I become root).

I do have the same problem: not being able to access the digital camera via
gphoto2. I did have libusb-0.1.12 installed, but downgrading to 0.1.11 doesn't
help. Changing permissions of /dev/bus/usb/ did actually help, so it seems to
me as if libusb-0.1.11 does have the same problem.

Ok, it also doesn't change when going back to 0.1.10a or 0.1.8 - so the root of
the problem must be something different.

(In reply to comment #42)
> I do have the same problem: not being able to access the digital camera via
> gphoto2. I did have libusb-0.1.12 installed, but downgrading to 0.1.11 doesn't
> help. Changing permissions of /dev/bus/usb/ did actually help, so it seems to
> me as if libusb-0.1.11 does have the same problem.
> 

Or the problem lies at least partly elsewhere.  Using either libusb 0.1.12 or
0.1.11, I can only access my camera as non-root with stable udev and a line in
10-local.rules for my camera.  Until recently was able to do so without the
local rule and using udev 096-r1.

The problem appears to be fixed since upgrade to gphoto2-2.2.0 and
libgphoto2-2.2.1-r1. I can now fully access my digital camera (Nikon Coolpix
4600) as a regular user.

libgphoto2-2.2.1-r1 fixed the problem for mee to. (Canon Digital Ixus 55)

So... everyone having the problem test w/ libgphoto2-2.2.1-r1 and report back
please...

/me still thinks udev is broken. I needed to change the usb_device rule in
50-udev.rules as Spanky suggested it in comment #11

The only problem I'm having with libgphoto2-2.2.1-r1 is the rules: get whole
bunch of these during gentoo part of bootup: udevd[1094]: add_to_rules: unknown
key 'ATTRS{idVendor}', in 'ATTRS{idVendor}'

Was helping out someone else getting this and they had this version. I upgraded
and got it also. Can't remember order of things right now, but downgraded back
to orig and still got it (perhaps orphaned udev rule file) and then removed
99-libgphoto2.rules file and error messages gone. Camera still worked, didn't
need rules.

Was just thinking. I don't need a rule for my camera, perhaps this error is
because don't have a rule?? If I don't have to have a rule for my camera I
don't think udev or libgphoto2 should be forcing me to make one just so it
doesn't produce those errors. Camera worked with or without the error messages
anyway. 

Otherwise, camera works with that version of libgphoto2, but 2 boxes I know of
get that output during boot with it. But right now haven't tested downgrading
again after deleting the udev rule file to see if it puts one there or leaves
an orphaned file. 

Ice storm of the centry hit us and have been without power for 2 1/2 days, will
test out later. 

I'm having the same problem, and spent several hours searching the forums and
other sources for a solution.  The USB_DEFVS_PATH env var works, but as
mentioned here, isn't ideal.  This udev rule works for me:

SUBSYSTEM=="usb_device", DRIVER!="usbhid", DRIVER!="hub", DRIVER!="hci_usb",
PROGRAM="/bin/sh -c 'K=%k; K=$${K#usbdev}; printf bus/usb/%%03i/%%03i
$${K%%%%.*} $${K#*.}'", NAME="%c", GROUP="plugdev", MODE="0664"

I put it in /etc/udev/rules.d/10-local.rules.  The idea here is that it doesn't
set change the permissions on things like mice, keyboards, the USB hub itself,
and (in my case) the hci_usb Bluetooth device.  It's probably not
security-conscious enough for everyone, but it lets me have access to any
camera plugged in, not just particular models.  Other libusb-based devices
should work just as well.

Since the original rule is still in 50-udev.rules, other devices will get the
default permissions.

Removing ppc from. Feel free to add us back if something ppc specific needs to
be done.

really removing ppc now :/
sorry for the bugspam

Reopen if you can reproduce with >=udev-104-r12; make sure you have *no*
stale/orphaned files in /etc/udev/rules.d, that you've emerged udev with
--noconfmem, that you've run etc-update or dispatch-conf after the upgrade and
merged all the updated properly and rebooted the box after that.

Works fine for me now!

(Spring cleaning.)

This works for me too.