Bug 427324

Summary: xsane doesn't get user permissions with hplip scanner
Product: [Fedora] Fedora Reporter: John Levon <levon>
Component: xsaneAssignee: Nils Philippsen <nphilipp>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: 8CC: twaugh
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: 2008-01-09 10:21:43 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 John Levon 2008-01-03 04:51:14 UTC
Description of problem:

I have a HP Photosmart C4180 All-In-One which uses the hplip
stuff to work. This works fine as root, but there's something
missing in the config such that the scanner is not available
as non-root.

Version-Release number of selected component (if applicable):

[root@rent ~]# rpm -q xsane
xsane-0.994-4.fc8
[root@rent ~]# rpm -qf /etc/security/console.perms
pam-0.99.8.1-10.fc8
pam-0.99.8.1-10.fc8


How reproducible:

Always.

Steps to Reproduce:
1. run xsane or gimp as non-root, observe lack of scanner

Notice log messages:

Jan  3 04:50:13 rent xsane: io/hpmud/musb.c 1880: invalid product id string:
Operation not permitted
Jan  3 04:50:13 rent xsane: io/hpmud/musb.c 1885: invalid serial id string:
Operation not permitted

Comment 1 Tim Waugh 2008-01-03 13:27:57 UTC
I think this may be related to bug #424331.  To be certain, we need to see what
the ACLs are for the relevant device node.  To do that, follow these steps:

Run '/sbin/lsusb' and find the bus and device numbers for the device, e.g. 003
and 002 here (for my PSC 2210):

...
Bus 003 Device 002: ID 03f0:2911 Hewlett-Packard 
...

Then run this command, substituting in the right numbers:

getfacl /dev/bus/usb/003/002


Comment 2 John Levon 2008-01-03 15:18:12 UTC
Looks like a similar problem indeed (got a good workaround?):

[root@rent rc.d]# lsusb
Bus 004 Device 001: ID 0000:0000  
Bus 003 Device 004: ID 046d:c001 Logitech, Inc. N48/M-BB48 [FirstMouse Plus]
Bus 003 Device 001: ID 0000:0000  
Bus 005 Device 001: ID 0000:0000  
Bus 002 Device 009: ID 03f0:5711 Hewlett-Packard 
Bus 002 Device 008: ID 0bc2:3000 Seagate RSS LLC 
Bus 002 Device 001: ID 0000:0000  
[root@rent rc.d]# getfacl /dev/bus/usb/002/009 
getfacl: Removing leading '/' from absolute path names
# file: dev/bus/usb/002/009
# owner: root
# group: lp
user::rw-
user:moz:rw-                    #effective:r--
group::rw-                      #effective:r--
mask::r--
other::r--


Comment 3 Tim Waugh 2008-01-03 17:32:16 UTC
This will correct the ACL mask:

setfacl -m m:rw- /dev/bus/usb/002/009

Investigation continues as to the cause and resolution of the problem.

Comment 4 John Levon 2008-01-09 03:48:47 UTC
I have the same problem printing.

syslog gives:

Jan  9 03:38:00 pent Photosmart_C4100_series?serial=MY64JB90MN04J7:
io/hpmud/musb.c 549: invalid product id string: Operation not permitted
Jan  9 03:38:00 pent Photosmart_C4100_series?serial=MY64JB90MN04J7:
io/hpmud/musb.c 1003: unable to open
hp:/usb/Photosmart_C4100_series?serial=MY64JB90MN04J7
Jan  9 03:38:00 pent Photosmart_C4100_series?serial=MY64JB90MN04J7: INFO: open
device failed; will retry in 30 seconds...

I fiddled with the settings of the usb file until eventually:

# getfacl /dev/bus/usb/002/014 
getfacl: Removing leading '/' from absolute path names
# file: dev/bus/usb/002/014
# owner: root
# group: root
user::rwx
group::r--
mask::rwx
other::rwx

Your workaround wasn't enough. Here's a history of what I fiddled with:

  750  setfacl -m m:rw- /dev/bus/usb/002/014 
...
  768  getfacl  /dev/bus/usb/002/014
  769  ls -l /dev/bus/usb/002/014 
  770  chmod g+w /dev/bus/usb/002/014 
  771  ls -l /dev/bus/usb/002/014 
  772  getfacl /dev/bus/usb/002/014
  773  man setfacl
  774  chmod 777 /dev/bus/usb/002/014 
  775  getfacl /dev/bus/usb/002/014 
  776  lsusb
  777  ls /dev/bus/usb/002/012 
  778  ls /dev/bus/usb/002/014 
  779  ls -l /dev/bus/usb/002/014
  780  getfacl /dev/bus/usb/002/014
  781  chmod g+x /dev/bus/usb/002/014 
  782  getfacl /dev/bus/usb/002/014
  783  chgrp root /dev/bus/usb/002/014 
  784  getfacl /dev/bus/usb/002/014
  785  ls -l /dev/bus/usb/002/014
  786  ps -ef | grep lpd
  787  ls -l /dev/bus/usb/002/014 
  788  ls -l /dev/bus/usb/002/014 
  789  getfacl /dev/bus/usb/002/014 


Comment 5 Nils Philippsen 2008-01-09 08:39:01 UTC
(In reply to comment #4)

> Your workaround wasn't enough. Here's a history of what I fiddled with:

Did you switch the printer on/off in between or unplug/re-plug it?

Comment 6 Tim Waugh 2008-01-09 10:21:43 UTC
Perhaps it failed in a slightly different way than for me.  The problem is now
understood to be a udev misconfiguration -- marking as a duplicate.

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