CUPS is unable to authenticate using kerberos (known bug)

Bug #572869 reported by Nikke
16
This bug affects 2 people
Affects Status Importance Assigned to Milestone
cups (Ubuntu)
Triaged
Medium
Unassigned

Bug Description

Binary package hint: cups

Hi all
Since before Ubuntu 9.10 there has been an issue with printing on a domain with kerberos authentication; I can print at home, but at the University I cannot.

The bug is related to CUPS and was introduced in version 1.4.0 somewhere (downgrading to 1.3.8 is said to be a work-around).
The bug is known by CUPS upstream, and there is a patch for it (http://www.cups.org/str.php?L3325). However, the patch is targeted for CUPS 1.5 with an undisclosed release date.

Now this is a complete printing show-stopper for me and many more (I guess). My solution now is to print to PDF, then boot windows in a virtualbox and print the PDF from within windows... Not an ideal solution.

Would it be possible to backport the patch from http://www.cups.org/str.php?L3325 to the current CUPS-version in Lucid.

All the best
Nikke

Timo Aaltonen (tjaalton)
Changed in cups (Ubuntu):
importance: Undecided → Medium
status: New → Triaged
Revision history for this message
Bart Vermeulen (bartverm) wrote :

I am also experiencing problems using cups with kerberos.

The problem is that cups runs the smb backend as root which doesn't know where to find the kerberos ticket (since the environment variable KRB5CCNAME is not defined there). Making a small script that exports the ticket cache name and than calls the backend does the job, but the ticket cache name changes name on every login (this can be changed though).

Calling the samba backend manually works perfectly fine and gives a message that it is using kerberos authentication.

Revision history for this message
Etienne Goyer (etienne-goyer-outlands) wrote :

To add to what Bart said above, CUPS backend are executed as user lp if they are world-executable, and by root is the backend is only executable by root. If the backend is to retrieve the user's credential, it has to be executed as root or as the user itself. So if you write a wrapper script for the smb backend, you need to make sure it is executable only by root.

Having a wrapper script setting KRB5CCNAME is a possible solution, but a more elegant one is to invoke smbspool as the user submitting the job, in which case it will pick up the Kerberos ticket just fine and do the right thing by itself. Minimally, something like the following would work:

----------------------------------------------------------------------
#!/bin/bash
su -c "/usr/bin/smbspool $1 $2 \"$3\" $4 \"$5\"" $2
----------------------------------------------------------------------

Nikke, I am not sure the problem you report is what we are actually talking about. The upstream CUPS bug you point to describe a different problem than the one we are having in Ubuntu, where Kerberos authentication is not even attempted in the first place. Can you describe your setup and your problem in more details?

Revision history for this message
Etienne Goyer (etienne-goyer-outlands) wrote :

I am tentatively marking this bug as a duplicate of bug #788167. Nikke, if the problem is not quite the same as what I reported there, please let me know and I will un-duplicate this one.

Revision history for this message
Nikke (nmellegard) wrote :

Hi Etienne and Bart
And, thanks for bringing attention to the bug...

It has been a while since I reported submitted the report and I must admit that I do not quite remember the details. I have since found a workaround (I'm able to access the printers directly, thus bypassing the print server entirely).

At the time, I found that my symptoms fitted the ones described in the CUPS report -- printing stopped working after CUPS upgrade from 1.3.8, the errors I got, an identical issue was seen by a collegue running OSX etc (and incidently I am at the same university as Micket in the CUPS report).

But, again, my conclusions were based on symptoms only. I'll see if I can find some time to investigate it again and will get back. So, keep it as a duplicate for the time being.

All the best
Nikke

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.