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
*** This bug has been marked as a duplicate of 121511 ***
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.