FS#26030 - [cups][libusb][hplip] CUPS permissions problem

Attached to Project: Arch Linux
Opened by Konstantin Gribov (gross) - Thursday, 15 September 2011, 17:40 GMT
Last edited by Andreas Radke (AndyRTR) - Saturday, 19 May 2012, 19:39 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Andreas Radke (AndyRTR)
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 3
Private No

Details

Description:
On CUPS updated to 1.5.0-1 local HP LaserJet 1300 (plugged by usb) stopped working. I deleted printer and tried to config it from scratch. CUPS ever doesn't see it in its web interface (with and without usblp module loaded into kernel).
hp-toolbox (from hplip) sees a printer and can add it to /etc/cups/printers.conf. But either in this situation printer fails to print with error like this:

D [15/Sep/2011:18:38:21 +0400] [Job 26] STATE: +connecting-to-device
D [15/Sep/2011:18:38:21 +0400] [Job 26] libusb couldn't open USB device /dev/bus/usb/007/004: Permission denied.
D [15/Sep/2011:18:38:21 +0400] [Job 26] libusb requires write access to USB device nodes.
D [15/Sep/2011:18:38:21 +0400] [Job 26] prnt/backend/hp.c 745: ERROR: open device failed stat=12: hp:/usb/hp_LaserJet_1300?serial=00CNCP048715
D [15/Sep/2011:18:38:21 +0400] [Job 26] Wrote 1 pages...
D [15/Sep/2011:18:38:21 +0400] [Job 26] Backend returned status 1 (failed)
D [15/Sep/2011:18:38:21 +0400] [Job 26] Printer stopped due to backend errors; please consult the error_log file for details.
D [15/Sep/2011:18:38:21 +0400] [Job 26] End of messages

Corresponding device owned by root:lp, perms: 0664, group lp in cupsd.conf SystemGroup. With 0660 permissions (as recomended on archwiki) it doesn't works too.

As a workaroud I added udev rule to set perms 0666, so printer works. But such solution is ugly.

Additional info:
extra/cups 1.5.0-1
core/libusb 1.0.8-1
extra/hplip 3.11.7-1
This task depends upon

Closed by  Andreas Radke (AndyRTR)
Saturday, 19 May 2012, 19:39 GMT
Reason for closing:  No response
Comment by Andreas Radke (AndyRTR) - Saturday, 01 October 2011, 09:00 GMT
can you try a generix cups own ppd driver? I assume this is a hplip permission issue. and make sure you belong to the lp group.
Comment by Konstantin Gribov (gross) - Sunday, 02 October 2011, 23:28 GMT
I'll try to check this version in a week.
I'm in lp group, root is too. Not under root, nor normal user (in lp group) I have no permissions to print something. It looks like dropping permission by cupsd.
Comment by Luis Manuel Ramos Da Costa (aliasbody) - Monday, 24 October 2011, 15:07 GMT
I also have this issue, I'm pretty sure it is a permission problem. When you "force" the permission of the printer for 777 (it is a bad idea but it's just an example), the printer start working with no problem.... Also, "cupsd-usblp" available in the aur do not solve the problem. (PS: I have a HP PSC 1200Series), If I could help with something just ask, I am not using Arch Linux just because of the printer :S
Comment by webdawg (webdawg) - Friday, 28 October 2011, 15:14 GMT
did you build the hp-plugin?
Comment by John Luebs (jkluebs) - Sunday, 15 January 2012, 08:17 GMT
I think there is a permissions problem with cups. I am not sure if other people are not seeing it for some reason. I have confirmed that cups is running external programs with a User of daemon and a group with nobody with no supplementary groups. Setting the User setting in cupsd.conf works, however the supplementary groups for the specified user are not set (whether this would be a bug or not is up for argument). The other problem is that the Group directive doesn't seem to do anything, if I set it to lp, the executables are still run with group nobody.
Comment by John Luebs (jkluebs) - Sunday, 15 January 2012, 08:21 GMT
Ok, seems cupsd runs as group nobody, but runs as uid 0 with full permissions, so I don't understand why it would not allow the group to be set in the configuration file.

EDIT: OK, so this was a problem on my end. I had added lp to the SystemGroup, which is not a good idea and I noticed the problem in the error_log, finally. Yes, I also noticed that this is documented properly in the Appendix on the wiki. So I don't know what the problem might for others.
Comment by Bill Sun (sib-null) - Wednesday, 18 January 2012, 00:33 GMT
I have very similar problems with my Canon Pixma MP500 and Brother HL-2040 printer, so this may not be an HP specific issue.

I'm experiencing the first symptom described which is that of my usb printers are not being detected by cups when I try to add the printers.

I installed TurboPrint, and TurboPrint was able to detect my Canon printer and install drivers for it. Next, I experienced the second symptom: I cannot print as I get the permission denied error, in my case, to /dev/usb/lp1. The device file is owned by root and part of lp group. I can only print after setting permissions to 666.

I haven't found much regarding the second symptom, but for the first symptom, I found the follow bugs reported:

https://bugs.launchpad.net/ubuntu/+source/cups/+bug/883169
This appears to be a problem in with a combination of kernel and cups version. This following comment reports that USB printer detection works with kernel 3.0.0-13 or newer and cups 1.5.0-11 or newer: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/883169/comments/18. The bug is marked as fixed.

https://bugs.launchpad.net/ubuntu/+source/cups/+bug/564917. This bug seem to have been resolved by the above.

https://bugs.launchpad.net/ubuntu/+source/cups/+bug/436495. It looks like blacklisting usblp is not a good idea.

@John Luebs, so how did you fix your problem? By removing lp from "# Administrator user group..." in cupsd.conf? This KDE wiki guide actually suggests the user to add it: https://wiki.archlinux.org/index.php/Kde#Printing

Edit: John, you are indeed correct. Removing "lp" from the Administrator user group allowed cups to print without any permission issues. I wonder why? The other effect of this is that my user can no longer administer cups. What is the correct approach to this?
Comment by John Luebs (jkluebs) - Wednesday, 18 January 2012, 04:14 GMT
Cupsd does not allow the Group directive (this is the group used by external cups helpers, including the gid to access the usb device nodes via the usb backend) to be an entry in SystemGroup (Administration user group). This enforcement is actually pretty reasonable and is to prevent a security risk. If an entry in SystemGroup is the value of the Group directive, the Group directive is forced to nobody. The gid of the usb backend will be nobody, which gets EPERM on a 0660 root:lp dev node. The fact that Group is being forced to nobody is placed in the error_log of cups if the LogLevel is debug, but it is easy to miss. What was confusing to me as well was that I didn't immediately assume that the arch cups PKGBUILD sets "Group" to lp by default (I assumed the default would be nobody), so the diagnostic didn't register until I realized cups was trying to use Group lp in the first place. One "correct" way to fix this is to create an lpadmin group (the name is arbitrary, but this seems to be popular in other distros, and what is suggested in the Arch wiki Cups appendix), and place that in SystemGroup. With this setup, your regular user account need not be in the lp group, just the lpadmin group.

EDIT: Ah, so not only does it look like the KDE wiki page is giving "bad" advice, so is the Cups wiki page (though the "Appendix" section "Alternative CUPS Interfaces" is OK).
Comment by Andreas Radke (AndyRTR) - Saturday, 03 March 2012, 15:16 GMT
Is this solved with your lpadmin suggestion or anything we can do in our way we package cups?
Comment by Andreas Radke (AndyRTR) - Friday, 18 May 2012, 08:58 GMT
cups 1.5.3 is out. anything we can do here in Arch?

Loading...