Bug 135803 - not so great permissions on USB scanners (and likely more)
not so great permissions on USB scanners (and likely more)
Status: CLOSED DUPLICATE of bug 121511
Product: Fedora
Classification: Fedora
Component: sane-backends (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Tim Waugh
Depends On:
  Show dependency treegraph
Reported: 2004-10-15 00:57 EDT by Michal Jaegermann
Modified: 2007-11-30 17:10 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-02-21 14:06:19 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Michal Jaegermann 2004-10-15 00:57:49 EDT
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
Comment 1 Tim Waugh 2004-10-15 04:29:39 EDT

*** This bug has been marked as a duplicate of 121511 ***
Comment 2 Red Hat Bugzilla 2006-02-21 14:06:19 EST
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.

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