Bug 135803 - not so great permissions on USB scanners (and likely more)
Summary: not so great permissions on USB scanners (and likely more)
Keywords:
Status: CLOSED DUPLICATE of bug 121511
Alias: None
Product: Fedora
Classification: Fedora
Component: sane-backends
Version: 3
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Tim Waugh
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2004-10-15 04:57 UTC by Michal Jaegermann
Modified: 2007-11-30 22:10 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2006-02-21 19:06:19 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

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.


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