Bug 427324 - xsane doesn't get user permissions with hplip scanner
xsane doesn't get user permissions with hplip scanner
Status: CLOSED DUPLICATE of bug 424331
Product: Fedora
Classification: Fedora
Component: xsane (Show other bugs)
8
All Linux
low Severity medium
: ---
: ---
Assigned To: Nils Philippsen
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-01-02 23:51 EST by John Levon
Modified: 2008-01-09 05:21 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-01-09 05:21:43 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description John Levon 2008-01-02 23:51:14 EST
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 08:27:57 EST
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 10:18:12 EST
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 12:32:16 EST
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-08 22:48:47 EST
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 03:39:01 EST
(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 05:21:43 EST
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 ***

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