Bug Description

Hi

After i've enabled ldap authentication on my PC (installed and configured libnss-ldap and libpam-ldap), cupsys printing stopped working. While printing a document, foomatic-rip consumes 100% cpu and I get several messages of the the following nature in dmesg:

IMHO, your bug report should be renamed to a line like the heading of my own comment.

Ubuntu cupsys 1.2.x packages are patched to retain the "RunAsUser" feature (which is now deprecated and removed -- for good reasons! -- by the original CUPS developers) in their distro, which makes cupsd run as user "cupsys" under all circumstances. (However, I assume this is just what Dapper inherited from Debian, and it is the same in Debian...).

That creates all kinds of problems when users want to follow one of the standard HOWTOs floating around the 'net to set up a certain behaviour of their printing system. Things like the ones outlined by a recent posting of Mike Sweet on CUPS.org don't work as expected:

- PAM-based local authentication (very likely the cause of your own
Ubuntu problem, reported as this bug #52350)

- support for legacy Unix clients via /etc/printcap or /etc/printers.conf
(probably never a problem for Ubuntu -- but running as user completely
breaks printing for all Gnome apps on Solaris 10, for example).

- future Kerberos support (as is currently under development by a Google
Summer of Code student)

At least, the "RunAsUser" experiment in CUPS 1.1.x was a *configurable* parameter, controllable via a cupsd.conf directive.

Now, what's the absolutely worst thing about the Ubuntu (and Debian as well ??) RunAsUser patch is that you can't set it back to "RunAsUser No"!

You can't re-gain the full original functionality of CUPS, as it was designed by its original developers: The Ubuntu(/Debian?) "RunAsUser" thingie is non-configurable; it is *not* an option to be reversed by a user; it is simply hard-coded into their patched sources.

You can't even work around it by by-passing the "/etc/init.d/cupsys start" script, and by starting "/usr/sbin/cupsd" directly as root from the commandline: cupsd will always run as the "cupsys" user...

In effect, this is not only a patch, it is a fork of CUPS (OK, I'll add another "IMHO" to my last sentence...).

After your suggestion, i've found out that the default install, for some reason did not add cupsys to the shadow group. Perhaps install scripts should sort that out, or did I miss something during the installation?

Adding cupsys to the shadow group fixes the printing issues, however, it introduces a security risk to the system. We all know that cupsys has a long history of vulnerabilities. Adding cupsys user to the shadow group could compromise the authentication information of the server, if one of the vulnerabilities is obused and local access to the server is obtained. From the security perspective, this, in turn, makes the option of running the service as unpriveleged user pointless. But I guess the cupsys developers and the debian/ubuntu team know what they are doing.

> After your suggestion, i've found out that the default install, for
> some reason did not add cupsys to the shadow group. Perhaps install
> scripts should sort that out, or did I miss something during the
> installation?

Exactly. cups user by default isn't part of shadow group. If you need
to read shadow, pam or ldap, you have to add it to shadow group. It's
that or runing it completly as root.

> Adding cupsys to the shadow group fixes the printing issues, however,
> it introduces a security risk to the system. We all know that cupsys
> has a long history of vulnerabilities. Adding cupsys user to the
> shadow group could compromise the authentication information of the
> server, if one of the vulnerabilities is obused and local access to
> the server is obtained. From the security perspective, this, in turn,
> makes the option of running the service as unpriveleged user
> pointless. But I guess the cupsys developers and the debian/ubuntu
> team know what they are doing.

If you add cupsys to shadow group, cupsys will be able to authenticate
user trough pam. If it isn't in shadow group, which is default, cupsys
user doesn't have any privileges. OTOH, if CUPS is runing under root
privileges (default by upstream), exploiting CUPS would be much worse
than exploiting Ubuntu's CUPS (attacker would have total, root,
control over computer). So, runining as unprivileged user isn't that
pointless, but then again it isn't bulletproof (*if* you add cupsys to
shadow).

This is how CUPS works now. Only way out of this situation (IMHO) is
rewriting CUPS in modular design (like postfix does it), but I'm the
wrong person to do that :)

We even can't secure it more in Ubuntu since current situation allready
introduces some functionality problems.

We are closing this bug report as it lacks the information, described in the previous comments, we need to investigate the problem further. However, please reopen it if you can give us the missing information and feel free to submit bug reports in the future.

I could stop and start the cupsd process without any issue until adding a printer into cups. At that point I got the segfault. I was trying to get authentication working so had added cupsys to the shadow group and modified the default cupsd.conf file to include the following

<Location /admin/conf>

AuthType Basic
Require user @SYSTEM
.....
</Location>

However backing out these changes still makes cupsd.conf segfault and I do not know how to remove the printer without being able to start the cupsd process.

My /etc/nsswitch.conf file has no reference to ldap in it. Just compat.

stevie - try editing /etc/cups/printers.conf as root with the text editor of your choice. For example - 'sudo vi /etc/cups/printers.conf'. http://answers.launchpad.net/ubuntu/ is a great place to ask questions like that.