Bug 135803

Summary: not so great permissions on USB scanners (and likely more)
Product: [Fedora] Fedora Reporter: Michal Jaegermann <michal>
Component: sane-backendsAssignee: Tim Waugh <twaugh>
Status: CLOSED DUPLICATE QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 3   
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-02-21 19:06:19 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Michal Jaegermann 2004-10-15 04:57:49 UTC
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
that.

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
hardware.

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

Comment 1 Tim Waugh 2004-10-15 08:29:39 UTC

*** This bug has been marked as a duplicate of 121511 ***

Comment 2 Red Hat Bugzilla 2006-02-21 19:06:19 UTC
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.