nsswitch.conf + ldap brakes cupsys printing

Bug #52350 reported by Mozg
2
Affects Status Importance Assigned to Milestone
cupsys (Ubuntu)
Invalid
Medium
Unassigned

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:

---snip---
[ 2530.243817] foomatic-rip[21141]: segfault at 00000000000000f0 rip 00000031d911766b rsp 00007fffff9c75b0 error 4
---snip---

While tracking down the problem, i've noticed that having the following entries in the nsswitch.conf crashes the foomatic-rip:

---snip---
passwd: compat ldap
group: compat ldap
shadow: compat ldap
---snip---

while the default entries in the nsswitch.conf produce no crash.

I am using an amd64 based Ubuntu 6.06 with up-do-date patches. If you require further information, I'll be glad to help

Thanks

Revision history for this message
Kurt Pfeifle (pfeifle) wrote : Ubuntu's hard-wired "RunAsUser cupsys" breaks CUPS authentication via nsswitch.conf + LDAP + PAM

Is your LDAP authentication working alright for other services?

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:

 - lpd backend printing towards older LPD servers which require source
   ports 721-731 (the CUPS option of appending "?reserve=yes" will fail)
   (see also Ubuntu bug #47773)

 - automatic root authentication via certificates (Ubuntu bug #26964 ?)

 - proxy authentication support in 1.2.x (no Ubuntu bug report [yet])

 - 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...).

Revision history for this message
Ante Karamatić (ivoks) wrote :

@ Mozg

Please provide your /etc/cups/cupsd.conf and relevant part of /var/log/cups/error_log. Also, make sure your 'cupsys' user is in shadow group.

Revision history for this message
Mozg (andrei-arhont) wrote :

Hi

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.

Thanks

Revision history for this message
Ante Karamatić (ivoks) wrote : Re: [Bug 52350] Re: nsswitch.conf + ldap brakes cupsys printing

On Thu, 13 Jul 2006 09:15:25 -0000
Mozg <email address hidden> wrote:

> 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.

So, OK to reject this bug as misconfigured?

--
Ante Karamatic | 0xD3BDA225 | 0x0A4A0161
<email address hidden> | <email address hidden> | ivoks.blogspot.com
"Tomorrow is my day off, so please stay off the powder!"

Revision history for this message
Ante Karamatić (ivoks) wrote :

PAM based authentication should be fixed in cupsys-1.2.2-0ubuntu2. Adding cups user to shadow group is no more needed. This package is in Edgy.

Revision history for this message
Ante Karamatić (ivoks) wrote :

Please report changes, when and if you try with new package.

Thank you.

Changed in cupsys:
importance: Untriaged → Medium
status: Unconfirmed → Needs Info
Revision history for this message
Brian Murray (brian-murray) wrote :

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.

Changed in cupsys:
assignee: nobody → brian-murray
status: Needs Info → Rejected
Revision history for this message
stevie (steve-lockdown) wrote :

Hi, I am seeing cupsd segfault as described above:

Jul 17 22:32:57 moose [736313.802274] cupsd[9830]: segfault at 0000000000000000 rip 000000000040bded rsp 00007fffff8115c0 error 4

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.

root@moose:/home/steve# uname -a
Linux moose.lockdown.nu 2.6.15-26-amd64-server #1 SMP Thu Aug 3 03:32:26 UTC 2006 x86_64 GNU/Linux

BTW am complete ubuntu/cups novice!

Revision history for this message
Brian Murray (brian-murray) wrote :

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.

Revision history for this message
stevie (steve-lockdown) wrote :

So I removed the printer config and restarted the cupsd however I still get the following in /var/log/messages:

Jul 18 06:53:12 moose [766292.125265] cupsd[11285]: segfault at 0000000000000000 rip 000000000040bded rsp 00007fffffe3f670 error 4

Do I continue with this bugid, or open a new one?

Changed in cupsys:
assignee: brian-murray → nobody
status: Invalid → Triaged
Revision history for this message
Phillip Susi (psusi) wrote :

Hardy has reached end of life, and this package is not present in later releases. Closing all related bugs.

Changed in cupsys (Ubuntu):
status: Triaged → Invalid
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.