cups not finding cups servers automatically

[Erik Bågfors]

I have a cups server that broadcasts it's printer information every 30 seconds
(default mode). Macs, SuSE-boxes, etc all find the server automatically by
listening to the broadcast. They all add the printer to for example the print
dialog in OOo.

Yet my ubuntu-boxes do NOT do this. I have verified that they recive the
broadcast by using ethereal.

Also, if using the gnome-cups-manager I get "No printers detected" although the
box get's the broadcast.

Perhaps this is just a setting in cups but I cannot find it and I also think
it's a bug that that setting is not default in that case.

Regards,
Erik

[Fabio Massimo Di Nitto (fabbione)]

For security reasons ubuntu does not ship any listening daemon:

http://wiki.ubuntulinux.org/SecurityPolicy

on the otherside we are still searching a way to let these kind of features to work
maintaing a high security profile.

To change the default settings you can check the cupsd.conf for browsing.

Downgrading this bug as enhancement request.

[Erik Bågfors (zindar)]

> To change the default settings you can check the cupsd.conf for browsing.

I'm blind, I've checked that file 10 times last night and didn't see it....

Thanks.

Erik

[Simon Oosthoek (simon-margo)]

to fix it, you also need to make cupsd listen on port 631 on all interfaces, not
just 127.0.0.1
so change:
Listen 127.0.0.1:631
to
Listen 631

I think this should be easy to turn on from some configuration thingy...

[Matt Zimmerman (mdz)]

(In reply to comment #3)
> to fix it, you also need to make cupsd listen on port 631 on all interfaces, not
> just 127.0.0.1
> so change:
> Listen 127.0.0.1:631
> to
> Listen 631

No, you need to change "Browsing off" to "Browsing on". This enables listening
on UDP port 631 on all interfaces. The Listen line affects the TCP port used to
serve printing requests, while browsing uses UDP on the same port.

The security model of this feature seems completely backwards: all clients must
open a port to listen for the server. A more logical approach would be for the
server to listen, and clients to send broadcasts when searching for printers
(e.g., when the configuration dialog is opened).

[Erik Bågfors (zindar)]

> The security model of this feature seems completely backwards: all clients must
> open a port to listen for the server. A more logical approach would be for the
> server to listen, and clients to send broadcasts when searching for printers
> (e.g., when the configuration dialog is opened).

Isn't this the same model as zeroconf/multicast dns/rendezvous/etc use? But then
multicast is different than broadcast...

[Matt Zimmerman (mdz)]

(In reply to comment #5)
> Isn't this the same model as zeroconf/multicast dns/rendezvous/etc use? But then
> multicast is different than broadcast...

I hope not, because it's rotten. Multicast and broadcast provide different
functionality, but they have the same security issues in this context.

[Martin Pitt (pitti)]

There's a fundamental contradiction, either we have no open ports in the default
install (which IMHO is a _very_ nice asset) or we let cups listen.

The best idea which I have about this would be a button "Search for network
printers" in the printer configuration dialog which listens to the network for
30 seconds. It's an ugly delay and still requires manual intervention, but it
would retain our security policy.

[Matt Zimmerman (mdz)]

A third option would be to fix CUPS to use a different security model for this
functionality. The natural approach would be:

- Server listens for broadcasts
- A client which is looking for printers to add sends a broadcast
- Servers respond to the broadcast
- Clients discover printers

I see no reason why this functionality should require that all clients listen on
a port by default.

This should be discussed with CUPS upstream to find a permanent solution.

[Martin Pitt (pitti)]

(In reply to comment #8)
> A third option would be to fix CUPS to use a different security model for this
> functionality. The natural approach would be:
>
> - Server listens for broadcasts
> - A client which is looking for printers to add sends a broadcast
> - Servers respond to the broadcast
> - Clients discover printers

The difficulty about this is that with CUPS there is not such a clear
distinction between servers and clients; it's more like a peer to peer protocol.
If browsing is enabled everywhere, then every computer automatically sees and
can use printers of every other computer.

Changing the currently used CUPS protocol is out of question, this would break
backward compatibility and interoperability with other systems. However, it
would be nice if an additional protocol could be created which uses
client-server like semantics. A computer becomes a server if a printer is
attached to it which shall be shared; a port must be opened in this case.

I will ask the CUPS developers about this. However, this is certainly not
something that will get finished within the Hoary release. In the meantime I do
not see another possibilty than setting "Browsing On" and "BrowseAddress @LOCAL"
manually in /etc/cups/cupsd.conf. Automatically mangling this configuration file
in gnome-cups-manager might be possible though, so this could at least get a GUI.

[Martin Pitt (pitti)]

I submitted this upstream:

http://www.cups.org/str.php?L1013+P0+S-2+C0+I0+E0+Q1013

[Martin Pitt (pitti)]

Upstream replied and it sounds as if they will not change the CUPS protocol for
this. So as long as we want to follow our default policy of no open ports, we
should leave browsing off by default and rather make it easy for the user to
enable it.

[gero (gerod)]

Please upgrade the severity of this bug. It cost me many hours to find the
problem and judging by the discussions you find, a large number of people made
the same experience. This is not just an enhancement--many users will simply not
get it to work as long as this security-induced bug is not even documented
anywhere in the CUPS management-system.

In my opinion the minimum fix would be some kind of notification in the Gnome
printer-manager to inform the user why no printers are discovered and how this
problem can be fixed.

[Matt Zimmerman (mdz)]

We understand and appreciate your concerns, but this does not change the
severity of the bug. If the protocol cannot be implemented within the terms of
our security policy, then we must forego this feature. This enhancement request
represents that missing functionality.

CCing Sebastien for input on whether there is a simple way to inform the user
that browsing is disabled, and possibly provide a checkbox to enable it (with a
warning about the effect on security)

[Martin Pitt (pitti)]

For the record, this is the current strategy:

cupsys:
- Split out the browsing part of the current configuration file into a separate
conffile; this allows to ship new main conffiles without dpkg questions.
- Ship two new helper scripts /usr/share/cups/browsing_status (returning exit
code 0/1/2) and /usr/share/cups/enable_browsing (taking a single parameter 0 or 1)

0: disabled, 1: enabled for local LAN, 2: custom configuration

gnome-cups-manager:
- If browsing_status is present and returns 0 or 1, display an additional checkbox

  [ ] Automatically use printers from LAN

On changing, this calls enable_browsing through gksudo; if this is enabled, a
warning message will pop up saying that this will open a port, which is a
potential security attack vector (however, the potential impact is limited to
the cups server, not to root).

[Martin Pitt (pitti)]

Backend part finished:
 cupsys (1.1.23-1ubuntu8) hoary; urgency=low
 .
   * debian/patches/ubuntu-localports.patch:
     - Removed "Browsing" patch hunk.
   * Added debian/patches/ubuntu-externalbrowseconf.patch:
     - Replace "Browsing" setting by "Include cupsd-browsing.conf" and update
       the documentation comment; this allows to enable/disable browsing
       without changing the main configuration file (which avoids dpkg
       questions on upgrades).
     - Enable "BrowseAddress @LOCAL" by default.
   * Added debian/local/cupsd-browsing.conf (single "Browsing" configuration
     parameter, default Off) and install it to /etc/cups/.
   * Added scripts to manage browsing status to debian/local and install them
     to /usr/share/cups/:
     - browsing_status: Return whether browsing is currently disabled (0),
       enabled (1) or there is a custom configuration (2).
     - enable_browsing: Enable (1) or disable (0) browsing. Only possible with
       non-custom configurations and with root privileges.
   * Backend part of Ubuntu bug #8975 (user-friendly browsing configuration).

[Sivan Greenberg (sivan)]

I am now going to add a menu item and a drop down "Browsing" to
gnome-cups-manager with two menu items, one for enabling browsing and one for
disabling it. Those would respectivly call on of Martin's scripts to enable or
disable to relevant part of the configuration file cupsd.conf to enable/disable
the browsing option.

As per Martin's suggestion, there is no real "main dialog" for g-c-m besides the
menubar, so adding it there, possibly adding it into the gnome-cups-add first
druid page.

[gero (gerod)]

@Martin, Sivan: Thanks, that sounds like a very good solution!
Martin, about cupsd-browsing.conf: To avoid dpkg questions, wouldn't it be
necessary to also externalize the BrowsePoll parameters that specify the CUPS
servers to poll?

[Martin Pitt (pitti)]

(In reply to comment #17)
> @Martin, Sivan: Thanks, that sounds like a very good solution!
> Martin, about cupsd-browsing.conf: To avoid dpkg questions, wouldn't it be
> necessary to also externalize the BrowsePoll parameters that specify the CUPS
> servers to poll?

Hmm, for me just giving an appropriate BrowseAddress (which will default to
@LOCAL) and enabling browsing works fine.

[gero (gerod)]

@Martin: If I'm not mistaken this approach only works as long as the CUPS
servers are on the same subnet as the client. (Which is not the case for me, nor
for many other corporate networks...)

[Sivan Greenberg (sivan)]

Created an attachment (id=1521)
debdiff to fix this boog.

[Sivan Greenberg (sivan)]

(In reply to comment #20)
> Created an attachment (id=1521) [edit]
> debdiff to fix this boog.
>

gnome-cups-manager (0.28-0ubuntu4) hoary; urgency=low

  * debian/patches/ui_browse_ctl.patch:
    - Patch to integrate IPP browsing control into the
      gnome-cups-manager GUI, and alert the user about
      opening port and it's implication as per Ubuntu
      security policy (Hoary: #2251).

[Martin Pitt (pitti)]

(In reply to comment #19)
> @Martin: If I'm not mistaken this approach only works as long as the CUPS
> servers are on the same subnet as the client. (Which is not the case for me, nor
> for many other corporate networks...)

This is right, but I think it is a sane and safe out-of-the-box default. People
who administrate multi-subnet corporate networks should be able to tweak the
settings to their specific needs anyway, I do not think that there is a sane
default that fits everywhere.

This default is intended to make printing on a small home network easy.

[gero (gerod)]

> This is right, but I think it is a sane and safe out-of-the-box default.
I'm not talking about any default. I'm talking about externalizing the
BrowsePoll parameter to cupsd-browsing.conf without changing its default. This
would make a lot of sense since it is a parameter that is likely to be changed
and externalizing it would avoid dpkg questions. That is what you intended with
introducing cupsd-browsing.conf, right? And I think that was a good idea. :-)

Please, move BrowsePoll to cupsd-browsing.conf. That would solve a problem
without causing any.

[Sivan Greenberg (sivan)]

already in archive, forgot to close the bug