Printing fails with "Unable to open print file"

[Cistoge]

Hello,

I have a number of machines where printing failed with error "Unable to open print file". As this error message is not especially meaningful, I edited the cups source code (backend/ipp.c) so that additionally the full path of the print file, the name of the process trying to open the print file and the effective UID and GID of that process were given.

So, I found that the print file was a temporary file in /tmp, belonging to user root and group lp, but only readable by root; that the process is named in the scheme (all printers are imported from remote by cups-browsed)

ipp://$RemoteHost:$RemotePort/printers/$Printer

which was running with effective UID of the user trying to print and effective GID lp.

Of. course, the print file could not be opened with these permissions.

But I had another machine where printing worked, with almost the same configuration, and found that there, the process named ipp://$RemoteHost:$RemotePort/printers/$Printer was running with effective UID 0.

So, I deinstalled and then reinstalled all cups packages, deleted all cups-related caches and spools I could find, and somehow after some tests I thought that the problem was solved, but now I have the same again: process with effective UID != 0 trying to open file exclusively accessible by root cannot open the file.

What can I do?

CUPS 2.4.2

Regards
Christoph

[michaelrsweet]

OK, so the only time the IPP backend changes users is for Kerberos support - are you using Kerberos?

If not, we need to know what Linux distro/OS you are using...

[Cistoge]

In the meantime, I found that the following happens:

At some point, cups calls the program implicitclass, which is part of cups-browsed. implicitclass runs with effective UID 0 and creates the temporary file that cannot be opened later.. Then, implicitclass calls the ipp backend of cups. That process also starts with effective UID 0, but later reduces permissions by setuid() with the UID of the user who wants to print.

Currently, I am wondering why in some occasions the permissions are not reduced ...

I am using cups 2.4.2-3+deb12u8 and cups-browsed 1.28.17-3+deb12u1, both from Debian bookworm.

[michaelrsweet]

Again, the setuid call is only invoked if the AUTH_UID environment variable is set. For CUPS, the only time this happens is for Kerberized printing.

I'm going to transfer this issue to the cups-browsed project which provides the implicitclass backend.

[Cistoge]

I have some kerberos related packages installed, probably as packages where other packages depend on, but I have not configured anything for kerberos and my cups DefaultPolicy is "authenticated".

At least temporarily, I solved the problem by lowering access rights with seteuid before creating tempfile_filter in implicitclass.c and restoring them afterwards.

[Cistoge]

What you probably mean is, that a setuid(AUTH_UID) only takes place if HAVE_GSSAPI is #defined, what is true, because cups was compiled with GSSAPI support. But having HAVE_GSSAPI #defined at cups compilation time does not imply in any way that at runtime Kerberos is used for authenticating print jobs or that the machine cups is running on is configured for any Kerberos authentication at all.