Red Hat Bugzilla – Bug 135803
not so great permissions on USB scanners (and likely more)
Last modified: 2007-11-30 17:10:51 EST
Description of problem:
This likely affects every device services by 'libusb' but I run
into that problem trying to get a working for non-root users
USB scanner. The thing is that we talk to such device through
a "node" in /proc/bus/usb/<something>/<something> and not anything
in /dev or /dev/usb.
If a hotplug event occured, and hotplug found a corresponding
script like /etc/hotplug/usb/libusbscanner, then there is a chance
that permissions on a node (a scanner needs a write access) were
adjusted provided it is possible to establish who is
$CONSOLEOWNER - if such entity does in fact exist which is very
far from obvious. A standard situation in my household is that
multiple X servers are running on different vts with active logins
from different users with widely differently looking desktops.
Moreover login is not a hotplug event and what pam does in
/dev, following rules in /etc/security, is in our situation
totally irrelevant. Also a hotplug event during a bootup,
with $CONSOLEOWNER probably empty, will not cause any adjustments.
Therefore the only reasonable solutions seems to be either
keep 666 permissions on the current node for libusb, or make
these 660 and owner a group, say, 'scanner' to which all
scanner-authorized accounts can be added. Otherwise there
is constant trouble with a scanner "vanishing" in an apperently
random manner (with "wrong" permissions sane reports that scanner
as a non-existent).
The above also implies that $CONSOLEOWNER if empty it should
be set to 'root.scanner', or 'scanner.scanner', or somethig like
Teaching users that they should flick a power button, or replug
a scanner cable, in order to "steal" scanner sounds to me like
a loosing proposition and is also quite heavy on a not so cheap
Version-Release number of selected component (if applicable):
sane-backends-1.0.14-6 but the problem is actually the
same at least in FC2
*** This bug has been marked as a duplicate of 121511 ***
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.