Bug 121511 - extend console.perms to cover /proc/bus/usb/*
extend console.perms to cover /proc/bus/usb/*
Status: CLOSED DUPLICATE of bug 177650
Product: Fedora
Classification: Fedora
Component: hotplug (Show other bugs)
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Bill Nottingham
: 121893 124053 125612 132194 135803 139203 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2004-04-22 04:33 EDT by Roland Wolters
Modified: 2014-03-16 22:44 EDT (History)
23 users (show)

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

Attachments (Terms of Use)
Example code to find libusb device given vendor and product IDs (774 bytes, text/plain)
2004-05-12 10:38 EDT, W. Michael Petullo
no flags Details
Modified usb.agent script (13.15 KB, text/plain)
2004-11-11 20:17 EST, Ian Pilcher
no flags Details
Modified libusbscanner script (2.59 KB, text/plain)
2004-11-11 20:23 EST, Ian Pilcher
no flags Details
A patch to /etc/security/console.perms that solves the bug for me. (431 bytes, patch)
2005-01-12 03:53 EST, Nick Urbanik
no flags Details | Diff

  None (edit)
Description Roland Wolters 2004-04-22 04:33:29 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (compatible; Konqueror/3.2; Linux) (KHTML, like Gecko)

Description of problem:
I am not able to use my scanner (mustek usb 1200 CU).
As user, scanimage -L only gives out my tv card, as root I can see the scanner with scanimage -L, but when I try to load xsane with this device, xsane hangs up.

I've tried to make a user group "scanner" and to add permissions to the directory /dev/usb/scanner0 or to /dev/sg0 or sga, but nothing helped.

Sandy Pond adviced me at the Fedora Mailing list (thx for that) to enter:
chmod 777 $(sane-find-scanner | &
            grep '^found USB scanner' | &
            sed -e 's?^.*libusb:?/proc/bus/usb/?' -e 's?:?/?')

It helps me to find the scanner with scanimage -L as user, xsane then shows it as device, but when I try to start with it, I get 

Failed to open device libusb:003:002
Error during I/O device.

Next try was to change the mustek_usb.conf file (the device Message from xsane talks about mustek_usb:libusb:003:002) from autodetect to usb libusb:003:002, but than scanimage is unable ot recognize it.

Xsane is able to scan pictures from my tv card, so the programm itself seem to work.

Fedora Core 1 was able to detect my scanner corectly, I am sorry that I am not sure about FC2t1, so maybe there is a problem with selinux?

Version-Release number of selected component (if applicable):
, sane-frontends-1.0.11-4

How reproducible:

Steps to Reproduce:
1. Install FC2t1 with an mustek 1200 CU USB Scanner
2. Update to development tree (last version tested: ~15. April 2004)
3. Look up scanimage -L as user or start xsane as root

Actual Results:  I am not able to find the scanner as user or to work with xsane as root.

Expected Results:  As user the scanimage -L should show the scanner (as in FC1), so that xsane works with it.

Additional info:
Comment 1 Tim Waugh 2004-04-22 04:45:05 EDT
"maybe there is a problem with selinux?" <- is SELinux enabled?  If
so, the first thing to do is disable it and see if things work then. 
If they do, then we know it's an SELinux problem -- if they don't of
course it isn't.
Comment 2 Jim Cornette 2004-04-22 07:19:03 EDT
I have a scanner that worked with the 2.4 kernels as joe user. It did
not work as a normal user with the 2.6 kernel.
After a discussion on the fedora-test list. I was led to try running
xsane as root user. It worked as root, to my surprise.
As a further test, I installed a fresh installation directly from the
4/21/04 devlopment tree. Then I tried xsane as user and it could not
find a device. I then tried as root on the fresh install and xsane
worked when run as root.

The version of scanner that I use is an HP ScanJet 2100C. I do not
have to configure anything to get this scanner model to function usually.
SELinix was not used in all cases.
Comment 3 Roland Wolters 2004-04-22 12:17:23 EDT
I tried to deactivate selinux with 'setenforce 0' as mentioned on the 
It does not help, it gives the same message out while trying to start 
xsane with the scanner. 
Failed to open device libusb:003:002 
Error during I/O device. 
Comment 4 Gerry Tool 2004-04-25 08:33:41 EDT
I just did a fresh install of FC2 Test3 from iso images.  My Epson
Perfection 1240U scanner which works great in FC1 (and many other
distros) by simply uncommenting the last line of
/etc/sane.d/epson.conf is not recognized by xsane.  SELinux is
supposed to be disabled by default in this install, so that is
probably not the issue. 

scanimage -L gives this result as root:

[root@gstpc sane.d]# 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).

sane-find-scanner gives this result as root:

[root@gstpc sane.d]# sane-find-scanner
found USB scanner (vendor=0x04b8 [EPSON], product=0x010b
[Perfection1240]) at libusb:003:002

running xsane as root or normal user gives the same "no devices
available" error.

Comment 5 Jim Cornette 2004-04-26 18:16:50 EDT
running sane-find-scanner as either a normal user or as root does not
find anything.
If I launch xsane as root, I can scan a picture.

I just downloaded the below versions of xsane and friends.

I'll try as a normal user and see if things are more sane, instead of
Comment 6 Jim Cornette 2004-04-26 18:23:49 EDT
With xsane-0.92-10 and xsane-gimp-0.92-10 installed, it still dos not
work from the launcher. It still works as root user for me.

I did not restart GNOME or try after a cold start. Are there any
lingering libraries that might need a restarted X session or
permission sets that might need to be set during the boot process?

Comment 7 Roland Wolters 2004-04-26 19:03:02 EDT
After the update, root with xsane is able to scan images. 
But user is stil unable to scan, 'scanimage -L' can't find the 
scanner, with  
chmod 777 $(sane-find-scanner | \ 
      grep '^found USB scanner' | \ 
      sed -e 's?^.*libusb:?/proc/bus/usb/?' -e 's?:?/?') 
'scanimage -L' find the scanner as user, but xsane still gives out 
the I/O error. 
Comment 8 Jim Cornette 2004-04-26 19:57:12 EDT
As root:
scanimage -L
device `plustek:libusb:001:004' is a Hewlett-Packard Scanjet 2100c USB
flatbed scanner

as a regular user:
 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).

I did not change file permissions or any configuration settings. It
detected the proper scanner, as root. Does the new usb driver for 2.6
need to be set to any permision that a regular user could use?

I checked the permissions for the driver for my scanner.

ls -l /usr/lib/sane/libsane-plustek.so.1.0.13
-rwxr-xr-x  1 root root 158000 Mar  5 01:34

Are these permissions rational? Or should they reflect a special group?

Comment 9 Jim Cornette 2004-04-26 21:08:40 EDT
I changed the permission of my usb device to allow write access also
to the scanner plustek:libusb:001:004
I changed to permission of /proc/bus/usb/001/004 to allow writing by
group and others. It scanned when I issued xsane
plustek:libusb:001:004 at the command line.
upon exiting the xsane program, I got the following error
"failed to create file, permission denied."

After clicking the close button on the above error dialog box, xsane
closed down.

dmesg reported this "badness"

ppdev0: registered pardevice
Badness in interruptible_sleep_on at kernel/sched.c:1927
Call Trace:
 [<022defe8>] interruptible_sleep_on+0x5a/0x230
 [<0211a4ba>] default_wake_function+0x0/0xc
 [<22ba9716>] parport_claim_or_block+0x22/0x50 [parport]
 [<22bc846e>] lp_write+0x1f3/0x2c7 [lp]
 [<0215c8ff>] vfs_write+0xb8/0xe4
 [<0215c999>] sys_write+0x2c/0x42
ppdev0: unregistered pardevice
ppdev0: registered pardevice
Badness in interruptible_sleep_on at kernel/sched.c:1927
Call Trace:
 [<022defe8>] interruptible_sleep_on+0x5a/0x230
 [<0211a4ba>] default_wake_function+0x0/0xc
 [<22ba9716>] parport_claim_or_block+0x22/0x50 [parport]
 [<22bc846e>] lp_write+0x1f3/0x2c7 [lp]
 [<0215c8ff>] vfs_write+0xb8/0xe4
 [<0215c999>] sys_write+0x2c/0x42
ppdev0: unregistered pardevice

done for tonite anyway!

Comment 10 Tim Waugh 2004-04-30 07:21:42 EDT
So does this line (in /etc/security/console.perms) need changing?:

<scanner>=/dev/scanner /dev/usb/scanner*

What happens if you add '/proc/bus/usb/*' to it?

Or do the hotplug scripts need something akin to
/etc/hotplug/usb/usbcam, for changing the permissions correctly?  What
happens if you copy /etc/hotplug/usb/usbcam to /etc/hotplug/usb/scanner?
Comment 11 Roland Wolters 2004-04-30 08:08:07 EDT
These lines changed nothign - do I have to reload anything to make 
them working? 
Comment 12 Tim Waugh 2004-04-30 08:52:12 EDT
Not sure.  I think this is something that needs help from a hotplug
script though. (CCing hotplug package maintainer.)
Comment 13 Jim Cornette 2004-04-30 18:01:08 EDT
My scanner works as regular user when the usb device permission is
changed to 006 but neither or the other permissions seem to make a
difference. Root can use the device also with the 006 permission.

chmod 006 /proc/bus/usb/001/004 makes the scanner work for all users.

I tried out the scanner on a system upgraded from FC1, an ftp install
from development and another FC2T1 to FC2T3 with the same results.

I have a hub connected to the USB port. My flash reader seems to work.
The USB hard disk is not recognized though. (Of course a different
problem for the USB hard disk. Though might be for the same reason.)
Comment 14 Roland Wolters 2004-05-01 11:59:21 EDT
You are right, I changed my permissions, too, and it works as user! 
chmod 006 /proc/bsu/usb/003/002 
Thx very much, 
Comment 15 Jim Cornette 2004-05-01 15:28:50 EDT
No problem with getting the hack to work. It would great for the
reason that the file for the usb device has 644 permissions originally
and does not work for the scanner. The only premission that seems to
matter is for the last permission to have rw access.
For now, setting the permission to allow others rw permission to the
device works. I also changed owner for the scanner device and xsane
recognized the scanner as a regular user. The file permissions were
still set to 644 with jim as the owner.

The problem seems to be that the usb device is mounted automatically
as root being the owner. Since the device is mounted, a regular user
cannot query for it, since it is only writable by root (the owner).

I think that the scanner device has to somehow be writable by all
users. How to do this is beyond my current knowledge.

Hopefully, this will work for the Fedora Core 2 release. What they did
for the 2.4 kernel to get scanners to work might need to be done for
the new usb drivers that the 2.6 kernel uses to get it to work without
manual trickery.
Comment 16 Tim Waugh 2004-05-02 17:46:52 EDT
As mentioned previously, this needs to be handled in exactly the same
way as USB cameras are now.  This needs to be done with a hotplug script.
Comment 17 Gerry Tool 2004-05-03 09:37:50 EDT
I have been trying to follow this bug report to get my Epson 1240U
scanner to work in FC2T3 with no luck.  Could someone post a complete
step-by-step procedure that gets the scanners working either in this
report, or to the fedora-test-list?


Gerry Tool
Comment 18 W. Michael Petullo 2004-05-03 10:22:38 EDT
*** Bug 121893 has been marked as a duplicate of this bug. ***
Comment 19 W. Michael Petullo 2004-05-03 10:23:44 EDT
From bug #121893:

Hotplug correctly sets the permissions of USB devices (ie:
/proc/bus/usb/001/*) when I plug in my digital camera.  Hotplug gives
read and write permissions to the console owner.

However, the same is not true for scanners.  Since the USB scanner
kernel module was dropped some time ago in favor of libusb, scanners
should be handled like digital cameras.

This is how I got my scanner to work right:

I added the following two lines to /etc/hotplug/usb.usermap (copied
from /etc/hotplug/usb.distmap -- the map for old kernel modules):

# Umax Astra 2200
scanner              0x0003 0x1606   0x0230    0x0000       0x0000   
   0x00       0x00            0x00            0x00            0x00   
        0x00       0x00000000

Then I copied /etc/hotplug/usb/usbcam to /etc/hotplug/scanner and
modified the script to reference scanners instead of cameras (actually
a slight modification of the same script could probably be used in
both cases).
Comment 20 Tim Waugh 2004-05-03 10:59:40 EDT
Please tell us exactly which modification you needed to make to the
script to get it to work -- I don't see anything camera-specific
there, so I must be missing something.
Comment 21 W. Michael Petullo 2004-05-03 12:53:19 EDT
I'm sorry, I should have been more clear in comment #19.  The only
thing in the script that is camera-specific is the comments.  The
actual logic of the script works fine out of the box with both
scanners and cameras.
Comment 22 Jim Cornette 2004-05-03 17:59:02 EDT
I noticed that this version was revised and has some script for USB


I haven't downloaded the latest version and tried it yet.

2004-05-01: SANE-Backends-1.0.14 has been released

    * New backend: u12
    * Updated backends: artec, artec_eplus48u, as6e, avision,
canon630u, canon_pp, epson, fujitsu, gphoto2, gt68xx, hp, matsushita,
mustek, mustek_pp, mustek_usb, plustek, plustek_pp, sm3600, snapscan,
teco1, teco2, u12, umax, umax_pp, v4l.
    * Added scripts for USB hotplugging (Linux)

The earlier update just stated that you need to change permissions as

With Linux 2.4.* you could either use the kernel scanner module or
libusb to
access USB scanners.  In Linux 2.6.4 the kernel scanner module was
Therefore with this and later kernels libusb must be used.

While SANE automatically uses libusb when the library and its header
file were
present during the build of sane-backends, setting permissions will
some attention.

The device files used by libusb are located in /proc/bus/usb/
(e.g. /proc/bus/usb/001/003).  The exact file name can be found out by
sane-find-scanner which would print "libusb:001:003" in this case.  While
setting permissions with e.g. "chmod a+rw /proc/bus/usb/001/003" seems
to work,
this change is not permanent.  The permissions will be reset when the
scanner is
replugged or Linux is rebooted.

One solution to set permissions on-the-fly are the Linux hot-plug
tools that
should come with any current distribution.  SANE itsself comes with a
script and related documentaion in the tools/hotplug/ directory.
Please refer to
the README in that directory for the details.

Comment 23 Tim Waugh 2004-05-04 09:20:30 EDT
Please try the 1.0.13-6 package:

Comment 24 Jim Cornette 2004-05-04 21:04:59 EDT
This solution is better than having to become root and then change the
file permissions as root.

ls -la /proc/bus/usb/001/* shows the scanner after unplugging the
scanner from the hub as 006 instead of 004 as it is when the system is
booted up. (Of course 004 does not exist now.)

 Thanks for the addition to sane-backends.

Jim (usb device permissions below, after replug of scanner)

-rw-r--r--  1 root root 43 May  4 20:53 /proc/bus/usb/001/001
-rw-r--r--  1 root root 43 May  4 20:53 /proc/bus/usb/001/002
-rw-r--r--  1 root root 50 May  4 20:53 /proc/bus/usb/001/003
-rw-r--r--  1 root root 50 May  4 20:53 /proc/bus/usb/001/005
-rw-------  1 jim  root 57 May  4 21:00 /proc/bus/usb/001/006
Comment 25 Roland Wolters 2004-05-05 02:48:02 EDT
I installed the new rpm, rebooted, and nothign changed - scanimage -L 
still gives out just my tv-card. 
Any hints what to do? Must I add something somewhere? 
Comment 26 Tim Waugh 2004-05-05 04:24:55 EDT
Roland: try powering off, and then on, the scanner after logging in.
Comment 27 Roland Wolters 2004-05-05 13:13:17 EDT
You are right, to power off and power on the scanner helps, is there 
any possibility to avoid this? 
Comment 28 Tim Waugh 2004-05-05 13:22:24 EDT
Suggestions welcome.
Comment 29 Sigge Kotliar 2004-05-08 12:04:35 EDT
I see a new sane-backends package hit rawhide today... still same
situation as before - works only after restarting the scanner...

Perhaps sane backends 1.0.14 solves this? Any change it could be
packaged before FC2 ships?
Comment 30 Tim Waugh 2004-05-09 06:19:40 EDT
Yes, it is intentional that it only works when the scanner is attached
after login.  No better solution has presented itself.

The upstream package uses a 'scanner' group -- which requires user
intervention to set up.

Eventually I think that pam_console (or something that invokes it)
will need to get these hotplug scripts run again, to simulate
unplug/insert events.  Digital cameras have the same issue.
Comment 31 W. Michael Petullo 2004-05-11 13:22:02 EDT
So pam_console should do something like this:

for each hot-pluggable device:
  # brute removal seems deadly: 
  export ACTION=remove
  export DEVPATH=/bus/usb/devices/<something>
  /sbin/hotplug usb.agent

  export ACTION=add
  export DEVPATH=/bus/usb/devices/<something>
  /sbin/hotplug usb.agent


Is there an easier way to say "re-execute all agents for all hotplug
devices?"  Or better yet, "re-set the permissions on all hotplug devices?"

Anyway, this seems like very important functionality because some USB
devices may not be realistically usable without it.
Comment 32 W. Michael Petullo 2004-05-12 10:38:08 EDT
Created attachment 100183 [details]
Example code to find libusb device given vendor and product IDs

Findusb.c is a simple program that prompts for a USB vendor and product ID and
prints the path to the corresponding libusb device.  This concept could be used
to allow pam_console to properly set the permissions on libusb devices.  The
configuration syntax of pam_console could be modified to support lines like the

<console> 0600 *1234-FEDC 0660 root.root

In this case, 1234 would be a USB vendor and FEDC would be a USB product.  * is
a sort of "dereference" operator.  Pam_console would then look up the
corresponding libusb device given this information and properly set its

To compile the example program:

gcc -lusb findusb.c
Comment 33 W. Michael Petullo 2004-05-12 19:21:23 EDT
Should this be filed against the pam package instead of sane-backends?
Comment 34 W. Michael Petullo 2004-05-12 20:55:44 EDT
After looking at pam_console some more I have realized that the idea
proposed in comment #32 could use some revising.  It would be very
neat if pam_console had some pre-defined file classes.  For example,
<libusb> could be recognized and cause /etc/hotplug/usb.usermap and
/etc/hotplug/usb/*.usermap (just like /etc/hotplug/usb.agent) to be
parsed for USB vendor and product IDs.  These, in turn, could be used
to determine the path respective libusb device (as described in
comment #32).  The permissions of the device could then be set.

Here is an example configuration line from /etc/security/console.perms:

<console>  0600 <libusb>        0600 root

An alternative would be to handle <usbscanner>, <usbcamera>, etc.
classes by parsing /etc/hotplug/usb.usermap or
/etc/hotplug/usb/libsane.usermap.  This may be easier to maintain but
would make the permission handling more fine-grained.

I would write a patch by I don't know lex, which is used by
pam_console to parse console.perms!
Comment 35 Tim Waugh 2004-05-13 07:48:44 EDT
This sounds like a good approach to me.  Changed summary and component.
Comment 36 Bill Nottingham 2004-05-19 17:52:35 EDT
Eventually, udev will handle this.
Comment 37 Heber Vazquez 2004-06-18 01:22:37 EDT
All my steps to do my scanner usb work on fedora core 2.  I think some
of them aren't needed but I do all of them.

[alpha:heberv] [~]$ sane-find-scanner
found USB scanner (vendor=0x04a5 [Color], product=0x20b0 [
FlatbedScanner 23]) at libusb:002:003

[alpha:heberv] [~]$ scanimage -L
device `snapscan:libusb:002:003' is a Acer FlatbedScanner23 flatbed

none            /proc/bus/usb   usbdevfs        defaults,mode=777    
  0 0

[alpha:root] [/etc]$ rpm -qa | grep sane

[alpha:root] [/etc]$ ls -ld sane.d/
drwxr-xr-x  2 root root 4096 Jun 18 00:00 sane.d/

[alpha:root] [/etc/sane.d]$ ls -la *.bin
-rw-rw-rw-  1 root root 30653 Jun 15 07:39 u176v042.bin

firmware /etc/sane.d/u176v042.bin

chgrp users  $(sane-find-scanner | grep '^found USB scanner' | sed -e
's?^.*libusb:?/proc/bus/usb/?' -e 's?:?/?')
chmod 0777 $(sane-find-scanner | grep '^found USB scanner' | sed -e
's?^.*libusb:?/proc/bus/usb/?' -e 's?:?/?')

# Acer Peripherals Inc.|S2W 3300U/4300U
scanner             0x0003      0x04a5   0x20b0    0x0000       0x0000
      0x00         0x00            0x00            0x00           
0x00               0x00               0x00000000


if [ "${ACTION}" = "add" ] && [ -f "${DEVICE}" ]
    # New code, using lock files instead of copying /dev/console
    # This also works with non-gdm logins (e.g. on a virtual terminal)
    # Idea and code from Nalin Dahyabhai <nalin@redhat.com>
    if [ -f /var/run/console.lock ]
        CONSOLEOWNER=`cat /var/run/console.lock`
    elif [ -f /var/lock/console.lock ]
        CONSOLEOWNER=`cat /var/lock/console.lock`
    if [ -n "$CONSOLEOWNER" ]
        chmod 0000 "${DEVICE}"
#        chown "$CONSOLEOWNER" "${DEVICE}"
        chgrp users "${DEVICE}"
        chmod 0777 "${DEVICE}"

[alpha:root] [/etc/hotplug/usb]$ ls -laR /proc/bus/usb/*
total 0
-rwxrwxrwx  1 root users 57 Jun 18 01:07 003

If I don't use the scanner in some time it turn off automatically (or
turn it off manually) and don't work as regular user, then I need to
log as user and call it on xsane again...

[alpha:root] [/etc/hotplug/usb]$ xsane
[snapscan] Scanner warming up - waiting 21 seconds.
[snapscan] Scanner warming up - waiting 21 seconds.

But finally work!
Comment 38 Tim Waugh 2004-06-29 09:42:37 EDT
        chgrp users "${DEVICE}"
        chmod 0777 "${DEVICE}"

Eek!  I don't think we want to do that!

The best solution I've seen, although it seems to be a work in
progress, is to have that script make a symlink for /dev/scanner to
point to the right place in /proc:

Comment 39 Tim Waugh 2004-07-12 11:19:51 EDT
*** Bug 125612 has been marked as a duplicate of this bug. ***
Comment 40 Tim Waugh 2004-09-07 05:01:52 EDT
*** Bug 131945 has been marked as a duplicate of this bug. ***
Comment 41 Tomas Mraz 2004-10-14 11:34:37 EDT
Moving to udev
Comment 42 Harald Hoyer 2004-10-14 11:50:30 EDT
nothing udev can do about that!
Comment 43 Tomas Mraz 2004-10-14 12:06:57 EDT
sorry, pam neither, maybe hotplug can?
Note that there is /dev/scanner and /dev/usb/scanner* entry in

Comment 44 Bill Nottingham 2004-10-14 12:18:28 EDT
Why wouldn't this be done in udev for things that match the proper
vendor/device IDs for scanners?
Comment 45 Harald Hoyer 2004-10-14 12:27:30 EDT
udev is for /dev
hotplug for the vendor/device, whatever... why not make this part of
remember this is /proc/bus/usb/ !!
Comment 46 Tim Waugh 2004-10-15 04:29:41 EDT
*** Bug 135803 has been marked as a duplicate of this bug. ***
Comment 47 Michal Jaegermann 2004-10-15 12:33:34 EDT
re comment #37:

Permissions 0777 are obviously excessive on a (pseudo)file in
/proc/bus/usb/<something>/<something>.  What do you want to execute
on your scanner?  But this is a perfect example what happens when
you restrictive beyond reason in some security settings.  Somebody
will eventually break that wide open beyond all imaginable needs
(one only wonders why suid, sid and sticky bits were not added too).

The recipe asked for in comment #17 is utterly trivial:
  - make sure that you have an entry for your USB scanner in
    /etc/hotplug/usb/libsane.usermap (add one if needed)
  - in /etc/hotplug/usb/libusbscanner put 'chmod 0666 "${DEVICE}"'
    before the last closing 'fi'; if  you need better access
    control then create a group 'scanner' (maybe both no-login
    user 'scanner' with a group 'scanner'), add all accounts
    authorized to use that device to a group 'scanner' and instead
    of 'chmod' above do 'chown scanner.scanner "${DEVICE}";
    chmod 0660 "${DEVICE}"'.

Whatever pam is happen to be doing is irrelevant.

It took me the whole twenty minutes to get my new scanner going with
FC2.  That long because this was an "unknown scanner" to a version
of sane included there.  Even less with FC3test where also some
small tweaks were still needed.  Querry in bugzilla failed somehow
to find that bug so I added 
with a bit more of details.  It looks from this long discussion
that I was lucky that my bugzilla search found nothing. :-)

BTW - the scanner works very nicely and even some persons around
here, who usually need to be shown things a few times, got themselves
beautiful scans when I was away. :-)
Comment 48 Ian Pilcher 2004-11-10 20:27:59 EST
Are there any plans to actually fix this?  You know, it's not like USB
scanners are common or anything.
Comment 49 Ian Pilcher 2004-11-11 20:17:29 EST
Created attachment 106546 [details]
Modified usb.agent script

Modified version of /etc/hotplug/usb.agent script.  The current version of this

script uses readlink to set the value of the REMOVER variable (see line 347).
This blows up when the sysfs entry no longer exists, which is the case during a

USB remove event.

I've changed the script to use a simple echo.  This makes REMOVER work for me
during USB remove events, but I'm not sure that it doesn't have negative 
consequences that I'm not seeing.  (And I've been told that asking about it on
the linux-hotplug-devel list is "flamebait".)

Comment 50 Ian Pilcher 2004-11-11 20:23:39 EST
Created attachment 106547 [details]
Modified libusbscanner script

Modified version of /etc/hotplug/usb/libusbscanner.

When used with the modified usb.agent script, this makes my USB scanner work
non-root users when it is "cold plugged".  It creates a symlink,
/dev/usb/scanner-BBB:DDD which points to the corresponding
file.  This makes pam_console set the permissions of /proc/bus/usb/BBB/DDD when
"console user" logs on.

When the scanner is cold plugged, the add event occurs before the root
filesystem is writeable, before /dev/usb exists, or both.  I've added a simple
loop to wait until /dev/usb exists, and this seems to work my my system, but,
with the modified usb.agent script, it really needs to be reviewed by someone
who understands the hotplug system.

Can we please get this fixed now?
Comment 51 Ian Pilcher 2004-11-12 12:46:41 EST
BTW, the version of this bug needs to be updated to FC3.
Comment 52 W. Michael Petullo 2004-11-13 17:10:42 EST
For what its worth: the folks who are working on gnome-volume-manager
and hal-cups-utils seem to be considering this issue with USB devices
already being plugged in when a user logs in.  See bug #132388,
comment 19.
Comment 53 Tim Waugh 2004-11-16 04:20:19 EST
*** Bug 139203 has been marked as a duplicate of this bug. ***
Comment 54 Tim Waugh 2004-11-16 12:43:14 EST
The libusbscanner part looks sane to me: I've built sane-backends-1.0.15-2 in
Fedora development. (Thanks!)
Comment 55 Bill Nottingham 2004-11-16 12:55:28 EST
hotplug part added in -10.
Comment 56 keith adamson 2004-11-17 01:44:31 EST
I hope that people realize that in a lot of instances scanners are
used by others than the console login user.  I think scanners are more
similar to printers than they are to cameras (they are accessed by
multiple users and normally are always connected to the computer).

I think that using the sane daemon "saned" with a secure initial setup
(similar to cups) may be the best approach.

In any case, tying the scanner to the console login user is not the
correct answer.
Comment 57 Michal Jaegermann 2004-11-17 10:18:46 EST
re comment #56:

You do not need an extra daemon _if_ pam does adjust correctly
initial permissions and permissions after every hotplug event.
What they should be is a matter of a local policy and adjustable
_then_ in /etc/security/console.perms.  I agree that 0600 for
an initial default is missing the point.  What that default should
be is a matter for a discussion but probably an extra group like
'scanner' and 0660 would be a reasonable compromise.  You can
find in /etc/security/console.perms examples of such arrangements
for other devices.  With that you have a control over which
accounts can, or cannot, use that scanner.

In a specific situtation 0666 configuration could be what is really
needed but that may be too loose for a general default (although
I do not see right now what harm that can do with a scanner plugged
and powered up).
Comment 58 David Lerner 2004-11-17 20:35:40 EST
0666 can do harm if a confidential document is left in a scanner. The
document is then world readable. It is also possible for a remote user
to grab a copy of a document during active use. This could be a real
problem in an office using NIS login, where any user can log onto any
Comment 59 keith adamson 2004-11-17 21:53:59 EST
I think that leaving a confidential document on a scanner is “world
readable” by default :).  The same as leaving one on a printer or
copier.  So I really don't see a problem with 0666 except for firmware

In any case, PAM doesn't do it for people that want to share a scanner
with those close by.  For instance we have several scanners within our
office that have auto-feeders for archiving and saving documents. 
These are used in the same manner as a printer would be (when is
someone going to make a “JetDirect” like scanner that is network plug
and play).  

If the daemon is used in a default fedora setup I hope it would be
initially configured to only accept connections from localhost
(similar to cups).
Comment 60 Tim Waugh 2004-11-18 04:11:56 EST
I think the question is whether saned has been audited recently.

Can anyone confirm that the pam_console fix works?
Comment 61 W. Michael Petullo 2004-11-18 23:55:50 EST
This seems to work for me.  The permissions of my scanner are changed
even when it was plugged in before I log in.  However, Fedora's strict
SELinux policy seems to break this.   This is a SELinux policy issue
and I will have to look into it another time.

So as far as this bug report goes, this looks fixed.

Comment 62 Tim Waugh 2004-11-19 07:47:08 EST
It would be useful to have the audit messages.  If you open a separate bug
report for this could you add a comment here with the bug number?  Thanks.
Comment 63 W. Michael Petullo 2004-11-19 11:06:49 EST
See bug #140059 for documentation about the SELinux issue.  I hope to
add more to this bug over the weekend.
Comment 64 Tim Waugh 2004-11-19 11:54:32 EST
Seems like the libusbscanner script doesn't handle the case of there being no
other USB devices on the system.  In that situation, /dev/usb will never be
created and the libusbscanner script will wait indefinitely.

Should it just make /dev/usb like this?:

mkdir -m 0755 -p /dev/usb

..or will that make the SELinux situation even worse?
Comment 65 Ian Pilcher 2004-11-19 12:51:02 EST
Note that the script currently uses the existence of /dev/usb as a
signal that udev is up and running.  If you simply create /dev/usb
in /dev, you risk doing it before udev is mounted on /dev.

Too bad none of the gurus on the hotplug mailing list will deign to
talk to mere users.
Comment 66 Tim Waugh 2004-11-19 13:00:45 EST
How about looping to wait for 'mount' to say it's mounted?
Comment 67 Gerry Tool 2004-11-19 13:25:25 EST
Scanner (Epson 1240U) still not detected for me with latest rawhide
sane-backends and hotplug installed.

[root@gstpc-fc3 ~]# rpm -q sane-backends
[root@gstpc-fc3 ~]# rpm -q hotplug

Scanner is not recognized until I execute a script to change
permissions, even if another USB device (USB flash drive) is active.

[root@gstpc-fc3 ~]# ls /dev/usb
ls: /dev/usb: No such file or directory
[root@gstpc-fc3 ~]# ps axf | grep sleep
 4124 ?        S<     0:00  |               \_ sleep 1
 4126 pts/2    S+     0:00          \_ grep sleep
[root@gstpc-fc3 ~]# ps axf | grep libusbscanner
 1336 ?        S<     0:00  |           \_ /bin/bash
 4132 pts/2    S+     0:00          \_ grep libusbscanner

I try to Acquire in Gimp at this point, and it fails to find scanner.

[root@gstpc-fc3 ~]# cat /usr/local/bin/fixscan
chmod a+w /proc/bus/usb/003/002
[root@gstpc-fc3 ~]# fixscan

Acquire with Gimp now works.  No change in above queries.

[root@gstpc-fc3 ~]# ls /dev/usb
ls: /dev/usb: No such file or directory
[root@gstpc-fc3 ~]# ps axf | grep sleep
 4210 ?        S<     0:00  |               \_ sleep 1
 4212 pts/2    R+     0:00          \_ grep sleep
[root@gstpc-fc3 ~]# ps axf | grep libusbscanner
 1336 ?        S<     0:00  |           \_ /bin/bash
 4219 pts/2    S+     0:00          \_ grep libusbscanner
Comment 68 Tim Waugh 2004-12-08 04:31:53 EST
Can you please try these packages from rawhide?:


If they work I would like to organise an official update for FC3.  If they
don't, well we need to fix it!
Comment 69 David Lerner 2004-12-13 21:48:41 EST
Upgraded with sane-backends-1.0.15-8 ad the -7 version is no longer
available. Upgraded hotplug and pam as shown above. Upgraded to
db4-3.21-1 as this was required by pam-0.78-2. Replaced
pam.d/system-auth with new version. Left unchanged modifications to
dll.conf and epson.conf. Used --force to upgrade db4.

With the above steps scanimage and xsane work as desired.

There appears to be some breakage as a result of the forced upgrade of
db4. I have not attempted to complete the upgrade dependency chain
caused by the db4 replacement.
Comment 70 Tomas Mraz 2004-12-14 03:26:16 EST
Use packages from FC 3 updates/testing they won't require new db4 so
you can downgrade it back to FC3 version.
Comment 71 David Lerner 2004-12-14 23:42:12 EST
Retested with the following packages from

Restored db4-4.2.52-6.i386.rpm and used rpmnew versions of dll.conf and

scanimage -L and xsane work correctly. This is a good fix.
Comment 72 Boris Goldowsky 2004-12-15 12:24:37 EST
The updates fixed the problem for me as well on my x86_64 system:
Dec 15 10:21:10 Updated: pam.x86_64 0.77-66.1
Dec 15 10:21:11 Updated: hotplug.x86_64 3:2004_04_01-8.1
Dec 15 10:21:16 Updated: sane-backends.x86_64 1.0.15-1.4
Dec 15 10:21:18 Updated: sane-backends.i386 1.0.15-1.4
Dec 15 10:21:21 Updated: pam.i386 0.77-66.1
Dec 15 10:21:21 Updated: pam-devel.x86_64 0.77-66.1

The only oddity was the creation of a number of .rpmnew files, all of
which appear to be identical to the existing config files.  I don't
know if this is the expected or correct behavior:

Updating: sane-backends 100 % done 3/12
warning: /etc/sane.d/abaton.conf created as /etc/sane.d/abaton.conf.rpmnew
warning: /etc/sane.d/agfafocus.conf created as
/etc/sane.d/agfafocus.conf.rpmnewwarning: /etc/sane.d/apple.conf
created as /etc/sane.d/apple.conf.rpmnew
warning: /etc/sane.d/artec.conf created as /etc/sane.d/artec.conf.rpmnew
warning: /etc/sane.d/artec_eplus48u.conf created as
warning: /etc/sane.d/avision.conf created as
warning: /etc/sane.d/bh.conf created as /etc/sane.d/bh.conf.rpmnew
warning: /etc/sane.d/canon.conf created as /etc/sane.d/canon.conf.rpmnew
warning: /etc/sane.d/canon630u.conf created as
/etc/sane.d/canon630u.conf.rpmnewwarning: /etc/sane.d/canon_pp.conf
created as /etc/sane.d/canon_pp.conf.rpmnew
warning: /etc/sane.d/coolscan.conf created as
warning: /etc/sane.d/coolscan2.conf created as
/etc/sane.d/coolscan2.conf.rpmnewwarning: /etc/sane.d/dc210.conf
created as /etc/sane.d/dc210.conf.rpmnew
warning: /etc/sane.d/dc240.conf created as /etc/sane.d/dc240.conf.rpmnew
warning: /etc/sane.d/dc25.conf created as /etc/sane.d/dc25.conf.rpmnew
warning: /etc/sane.d/dll.conf created as /etc/sane.d/dll.conf.rpmnew
warning: /etc/sane.d/dmc.conf created as /etc/sane.d/dmc.conf.rpmnew
warning: /etc/sane.d/epson.conf created as /etc/sane.d/epson.conf.rpmnew
warning: /etc/sane.d/fujitsu.conf created as
warning: /etc/sane.d/gt68xx.conf created as /etc/sane.d/gt68xx.conf.rpmnew
warning: /etc/sane.d/hp.conf created as /etc/sane.d/hp.conf.rpmnew
warning: /etc/sane.d/hp5400.conf created as /etc/sane.d/hp5400.conf.rpmnew
warning: /etc/sane.d/hpsj5s.conf created as /etc/sane.d/hpsj5s.conf.rpmnew
Updating: sane-backends 1 % done 4/warning: /etc/sane.d/ibm.conf
created as /etc/sane.d/ibm.conf.rpmnew
warning: /etc/sane.d/leo.conf created as /etc/sane.d/leo.conf.rpmnew
warning: /etc/sane.d/ma1509.conf created as /etc/sane.d/ma1509.conf.rpmnew
warning: /etc/sane.d/matsushita.conf created as
warning: /etc/sane.d/microtek.conf created as
warning: /etc/sane.d/microtek2.conf created as
/etc/sane.d/microtek2.conf.rpmnewwarning: /etc/sane.d/mustek.conf
created as /etc/sane.d/mustek.conf.rpmnew
warning: /etc/sane.d/mustek_pp.conf created as
/etc/sane.d/mustek_pp.conf.rpmnewwarning: /etc/sane.d/mustek_usb.conf
created as /etc/sane.d/mustek_usb.conf.rpmnew
warning: /etc/sane.d/nec.conf created as /etc/sane.d/nec.conf.rpmnew
warning: /etc/sane.d/net.conf created as /etc/sane.d/net.conf.rpmnew
warning: /etc/sane.d/pie.conf created as /etc/sane.d/pie.conf.rpmnew
warning: /etc/sane.d/plustek.conf created as
warning: /etc/sane.d/plustek_pp.conf created as
warning: /etc/sane.d/qcam.conf created as /etc/sane.d/qcam.conf.rpmnew
warning: /etc/sane.d/ricoh.conf created as /etc/sane.d/ricoh.conf.rpmnew
warning: /etc/sane.d/s9036.conf created as /etc/sane.d/s9036.conf.rpmnew
warning: /etc/sane.d/saned.conf created as /etc/sane.d/saned.conf.rpmnew
warning: /etc/sane.d/sceptre.conf created as
warning: /etc/sane.d/sharp.conf created as /etc/sane.d/sharp.conf.rpmnew
warning: /etc/sane.d/snapscan.conf created as
warning: /etc/sane.d/sp15c.conf created as /etc/sane.d/sp15c.conf.rpmnew
warning: /etc/sane.d/st400.conf created as /etc/sane.d/st400.conf.rpmnew
warning: /etc/sane.d/tamarack.conf created as
warning: /etc/sane.d/teco1.conf created as /etc/sane.d/teco1.conf.rpmnew
warning: /etc/sane.d/teco2.conf created as /etc/sane.d/teco2.conf.rpmnew
warning: /etc/sane.d/teco3.conf created as /etc/sane.d/teco3.conf.rpmnew
Updating: sane-backends 1 % done warning: /etc/sane.d/test.conf
created as /etc/sane.d/test.conf.rpmnew
warning: /etc/sane.d/u12.conf created as /etc/sane.d/u12.conf.rpmnew
warning: /etc/sane.d/umax.conf created as /etc/sane.d/umax.conf.rpmnew
warning: /etc/sane.d/umax1220u.conf created as
/etc/sane.d/umax1220u.conf.rpmnewwarning: /etc/sane.d/umax_pp.conf
created as /etc/sane.d/umax_pp.conf.rpmnew
warning: /etc/sane.d/v4l.conf created as /etc/sane.d/v4l.conf.rpmnew
Updating: sane-backends 100 % done 4/12
warning: /etc/pam.d/other created as /etc/pam.d/other.rpmnew
warning: /etc/security/access.conf created as
warning: /etc/security/chroot.conf created as
warning: /etc/security/group.conf created as
warning: /etc/security/limits.conf created as
warning: /etc/security/opasswd created as /etc/security/opasswd.rpmnew
warning: /etc/security/pam_env.conf created as
/etc/security/pam_env.conf.rpmnewwarning: /etc/security/time.conf
created as /etc/security/time.conf.rpmnew
Comment 73 Tim Waugh 2004-12-15 12:38:11 EST
Boris: thanks for the feedback.  These multilib conflicts are noted in bug #135172.
Comment 74 Jim Cornette 2004-12-19 22:07:26 EST
I tried out the scanner today and it worked without any additionals
steps needed. This is much nicer from a user experience.


I did not have any package conflict issues.
Comment 75 Gerry Tool 2004-12-20 09:57:46 EST
My epson 1240u scanner will still not work without a change of
permissions as root.  I have

[root@gstpc-fc3 ~]# rpm -q sane-backends
sane-backends-1.0.15-2          #from normal updating
[root@gstpc-fc3 ~]# rpm -q hotplug
hotplug-2004_04_01-10           #from normal updating
[root@gstpc-fc3 ~]# rpm -q pam
pam-0.77-66.1                   #downloaded and installed by me

To make it available, I execute

chmod a+w /proc/bus/usb/003/002

What am I missing?  A reboot didn't help.
Comment 76 Tim Waugh 2004-12-20 10:08:21 EST
Gerry: not sure how you ended up with sane-backends-1.0.15-2: that's the wrong
one.  Get the package from FC3 updates-testing: 1.0.15-1.4.
Comment 77 Gerry Tool 2004-12-20 10:37:23 EST
Thanks, Tim.  Downgrading to sane-backends-1.0.15-1.4 fixed it.

I coudn't get around to trying your fix until this morning and by then, normal
updates as prompted by the rhn applet had installed sane-backends-1.0.15-2.
Comment 78 david walcroft 2004-12-27 22:12:49 EST
I'm using a HP psc2110 multi-function usb dev. with an update as shown
usb scanning will not work.
[david@reddwarf ~]$ rpm -qa | grep sane
[david@reddwarf ~]$ rpm -qa | grep hotplug
[david@reddwarf ~]$ rpm -qa | grep pam
[david@reddwarf ~]$ sane-find-scanner
found USB scanner (vendor=0x03f0 [Hewlett-Packard], product=0x2811
[PSC 2100 Series]) at libusb:003:004
[david@reddwarf ~]$ scanimage -L

No scanners were identified.
chmod a+w /proc/bus/usb/003/004 makes no difference
Comment 79 Tim Waugh 2004-12-30 08:14:50 EST
david walcroft: you need to install libsane-hpoj and set up hpoj.  Your problem
is not related to this bug report.
Comment 80 Ken Giusti 2004-12-31 09:51:51 EST
Hi - just my $0.02:

I've got a fresh install and fully-patched version of fc3.  I was
experiencing the same permission problems when using SANE with my
epson 1240U scanner.  Upgrading to the following versions of hotplug
and sane-backends (from updates testing) solved the problem.  I can
now scan from a non-root user account.  Thanks!


(pam is already patched to pam-0.77-66.1 after up2date patching)

Comment 81 david walcroft 2005-01-01 01:53:44 EST
Reply to #79.
Thanks Tim it works now and will test later
Comment 82 Janos Lichtenberger 2005-01-11 04:50:20 EST

I have a Canon 5000F USb scanner. It does not work under FC3. I tried
the the pacjakes mentioned in e.g. in #74:
root@hopkins ~]rpm -q sane-backends
[root@hopkins ~]# rpm -q hotplug
[root@hopkins ~]# rpm -q pam
[root@hopkins ~]# sane-find-scanner

  # No SCSI scanners found. If you expected something different, make
sure that
  # you have loaded a SCSI driver for your SCSI adapter.
  # Also you need support for SCSI Generic (sg) in your operating system.
  # If using Linux, try "modprobe sg".

found USB scanner (vendor=0x04a9 [Canon], product=0x2212 [CanoScan])
at libusb:001: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.

  # Not checking for parallel port scanners.

  # Most Scanners connected to the parallel port or other proprietary
  # can't be detected by this program.
root@hopkins ~]# 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).

I tried to make a new backend for this scanner modifying canon630u.conf 
root@hopkins sane.d]# cat canon5000f.conf
# Options for the canonusb backend

# Autodetect the Canon CanoScan 5000F
usb 0x04a9 0x2212

# device list for non-linux-systems (enable if autodetect fails):

The results was the same.

Janos Lichtenberger
Comment 83 Tim Waugh 2005-01-11 05:14:45 EST
This bug report is for permissions problems, which I think are now fixed.

Please open a separate bug report for backend problems.  thanks.
Comment 84 Michal Jaegermann 2005-01-11 11:06:46 EST
> I have a Canon 5000F USb scanner. It does not work under FC3
> found USB scanner (vendor=0x04a9 [Canon], product=0x2212 [CanoScan])
> at libusb:001:003
> # scanimage -L
> No scanners were identified.

This a typical response from 'scanimage' when a scanner was actually
identified but you do not have __write__ permissions on a needed
device node.  In the case above on /proc/bus/usb/001/003.  This may
happen when:
  a. /etc/hotplug/usb/libsane.usermap is missing an entry for your
     scanner and you have add one yourself (not the case here AFAICS)
  b. /etc/hotplug/usb/libusbscanner does not run, or is "old", or
     is messed up by some other reasons; run yourself providing
     required arguments and see what happens
  c. <scanner> entry in /etc/security/console.perms is of such sort
     that results are not writable
  d. if you checked all the above and perms on /proc/bus/usb/001/003,
     or whatever that may be in a given moment, are indeed correct
     that, as Tim says, this is something else and open a new bug.
Comment 85 Tim Waugh 2005-01-11 11:09:16 EST
('scanimage -L' had been run as root, and so it is not a permissions issue.)
Comment 86 Nick Urbanik 2005-01-12 03:53:02 EST
Created attachment 109660 [details]
A patch to /etc/security/console.perms that solves the bug for me.
Comment 87 Nick Urbanik 2005-01-12 03:58:55 EST
The file /dev/scanner* is a symbolic link to the file that needs its
ownership changed:
$ ls -l /dev/scanner*;ls -Ll /dev/scanner*
lrwxrwxrwx  1 root root 21 Jan 12 14:08
/dev/scanner-usb-:proc:bus:usb:005:006 -> /proc/bus/usb/005/006
-rw-------  1 nicku root 50 Jan 12 14:08

The fix given in the patch above changes one line in
/etc/security/console.perms from:
<scanner>=/dev/scanner /dev/usb/scanner*
<scanner>=/dev/scanner* /dev/usb/scanner*

Is there any security problem that anyone can see in this simple fix?
 All the other solutions just seem like too much work to me.
Comment 88 Tim Waugh 2005-01-12 04:16:56 EST
Nick: this change does not apply to the console.perms shipped with Fedora Core 3
in the pam package.  That file already has /dev/scanner*.

This bug remains open only because the SELinux bug it depends on is not
confirmed closed.
Comment 89 Bill Nottingham 2005-02-04 16:06:58 EST
*** Bug 124053 has been marked as a duplicate of this bug. ***
Comment 90 Bill Nottingham 2005-02-04 16:11:07 EST
*** Bug 132194 has been marked as a duplicate of this bug. ***
Comment 91 Arthur Baldwin 2005-12-15 14:49:04 EST
I'm getting upset...I know this is not good for finding a solution.  But I have
customers waiting for the ability to use their desktop scanners as a normal
user.  I have tried the suggestions listed here to no avail.  I'm using a fully
updated version of FC4 with "updates-testing" enabled in order to take advantage
of the updates to packages hotplug and sane-backends.  My scanner is an "Epson
Perfection 4870" USB scanner.  I have tried modifying the console.perms file. 
And a few other ideas listed in this bugzilla entry...but nothing works.  I can
still use the scanner as root, but not as arthur.  I thought this would be fixed
long ago.
Comment 92 Arthur Baldwin 2005-12-15 15:27:02 EST
ok...was able to use lsusb to find the proper device and use Konqueror to change
the permissions quickly and easily to get GIMP able to acquire.  But this is NOT
a good solution because turning the scanner off and back on puts me back at
square one.  I have found solutions to a few other bugs in FC4 and this one is
the "last one" that I need to solve before heartily recommending FC4 to novice
computer users.  I was successful in getting Sun's version of JRE, J2SE, J2EE,
and NetBeans all working perfectly...so I can visit websites with Java stuff. 
And I fixed the sound for Flash by deleting the file libnullplugin.so in
/usr/lib/firefox-1.0.7/plugins directory before auto-installing the plugin. 
Then I fixed the automounting of floppies and CD's.  So I do have some skill. 
But this scanner thing is driving me nuts.
Comment 93 Arthur Baldwin 2005-12-16 08:26:22 EST
I finally decided to give the "development" channel a try and found newer
versions of hotplug and sane* packages, but all of the sane* packages fail on a
long list of dependencies.  So I left the sane* packages uninstalled.  With the
development version of hotplug installed the problem remains.
Comment 94 Bill Nottingham 2006-01-18 11:10:00 EST
Closing this as a dup, as I posted some potential fixes in the other bug (sorry,
didn't see this one first.) Testers needed, though, as I don't have the hardware. 

*** This bug has been marked as a duplicate of 177650 ***
Comment 95 Jim Cornette 2006-01-24 14:23:01 EST
With the changes to console, the HP scanner that I use works fine and
permissions do not need to be set.
I will examine bug 177650 to see if similar to this problem.

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