[Gutsy SRU Request] CUPS 1.3.x lists network interfaces only at startup (regression)

Bug #177075 reported by Hugues Fournier on 2007-12-18
4
Affects Status Importance Assigned to Milestone
cups (Debian)
Fix Released
Undecided
Unassigned
cupsys (Ubuntu)
Medium
Unassigned
Gutsy
Undecided
Unassigned

Bug Description

Binary package hint: cupsys

Problem:
From CUPS 1.3.x, except at startup, network interfaces are not anymore polled for changes (appearance and disappearance of a network interface, and any IP address or mask change).

This means that in a CUPS configuration allowing local connection (sharing of local printer on local network), any connection from a local ip coming on an interface that appeared after CUPS startup (in my case a vpn one), is refused (403 error). And as a result, obviously, printer is not shared on the local network related to this interface.

The user has to restart cupsd in order to make cups accept connection on these new network interfaces.

Until recently this was difficult to see, because there was another problem affecting sharing in gutsy and hardy, that was necessitating a restart of cupsd (the late start of avahi, recently fixed in bug 173470 ).

Fix:
I have tracked it down and in fact, the problem appeared with revision 6123 (pre 1.3.0) in cups svn trunk, that was landing a multiplatform management of poll (use of poll(), epoll(), or kqueue() depending of the platform). Part of this checkout moved the Mac OS X specific call to cupsdUpdateSystemMonitor in main.c to a select callback in sysman.c (we don't care), but in the same time it removed (inadvertantly) in main.c the set of NetIFUpdate to 1 every minute or so for all other OS (here, we care ;-) )

See:
svn diff -c 6123 http://svn.easysw.com/public/cups/trunk/scheduler/main.c (look for NetIFUpdate)
and more generally
svn diff -c 6123 http://svn.easysw.com/public/cups/trunk/scheduler/ (to check that this checkout did not reintroduced the code removed anywhere in the scheduler else (except for Mac OS X) )
svn log -r 6123 http://svn.easysw.com/public/cups/trunk/

I have reported the problem upstream on Sunday :
http://www.cups.org/str.php?L2631

with a patch :
http://www.cups.org/strfiles/2631/interface-update_v2.patch

TEST CASE:
Edit /etc/cups/cupsd.conf in order to get a basic local sharing configuration : change "Listen localhost:631" to "Port 631" and "Browsing Off" to "Browsing On"

Get your networking off to start it only after CUPS :
1) sudo /etc/init.d/networking stop
2) sudo /etc/init.d/cupsys restart
3) sudo /etc/init.d/networking start

After these restarts, any CUPS connection coming from the local network is refused if the bug is present
This can be checked from a remote box on the LAN by trying to access *more than 1 minute* after restart to http://<cupsserveripaddressonthelan>:631 , that leads to a 403 error if the bug is present.

The 1 minute wait is needed because the check for new network interfaces takes place once a minute.

Note that CUPS correctly broadcast on the local network (test: avahi-browse -k -t -v -r -a) whether or not this bug is present, but this is useless if it is refusing connections..

CVE References

Here is a debdiff for hardy.

My proposed patch has been committed with some cosmetic changes some minutes ago upstream (so it will be fixed in the future 1.3.6 release)

See: upstream revision 7141
svn log -r 7141 http://svn.easysw.com/public/cups/trunk/
svn diff -c 7141 http://svn.easysw.com/public/cups/trunk/

I will upload a debdiff shortly including these cosmetic changes.

I do not think it is necessary (it's just a different commentary, an inversion of two consecutive lines, and a different line for a variable declaration, so in fact nothing different) but it will make easier to detect when the patch will be useless in a future version.

Changed in cupsys:
status: New → Triaged
importance: Undecided → Medium
status: New → Confirmed
Till Kamppeter (till-kamppeter) wrote :

I have applied the patch to the Debian SVN repository now. It will soon be merged into the Ubuntu cupsys 1.3.5 package.

Changed in cupsys:
status: Confirmed → Fix Committed
status: Triaged → In Progress
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package cupsys - 1.3.5-1ubuntu1

---------------
cupsys (1.3.5-1ubuntu1) hardy; urgency=low

  * Merge with Debian unstable; remaining Ubuntu changes:
    - TearDown (fast shutdown):
      + debian/control: Add sysv-rc (>= 2.86.ds1-14.1ubuntu2) dependency.
      + debian/rules: Use 'multiuser' update-rc.d mode.
    - debian/control, debian/rules: Drop cupsys-dbg package.
    - debian/cupsys.{pre,post}inst, debian/cupsys.preinst: Various upgrade
      fixes that need to be kept until after the next LTS:
      + Revert to single cupsd.conf file.
      + Remove obsolete rc.d links.
      + Revert usr/share/doc symlink/directory breakage.
    - debian/patches/ubuntu-default-error-policy-retry-job.dpatch: Retry a
      failed job instead of stopping the print queue.
    - debian/patches/ubuntu-disable-browsing.dpatch: Disable browsing by
      default.
    - Add AppArmor profile:
      + debian/local/apparmor-profile
      + debian/cupsys.postinst: Reload AA profile on configuration.

cupsys (1.3.5-1) unstable; urgency=high

  [ Kenshi Muto]
  * New upstream release
    - cups-stops-broadcasting-on-HUP-with-explicit-BrowseAddress patch is
      merged.
    - Fix that SNMP backend did not check for negative string lengths.
      (CVE-2007-5849, closes: #457453).
  * Update pdftops.pl to 1.20. It fixes overwriting arbitary files
    via symlink attack. (CVE-2007-6358, closes: #456960)

  [ Till Kamppeter ]
  * debian/patches/fix_regression_reactivate_net_ifaces_changes_detection.dpatch :
    Fix a regression in upstream code that has removed the network interface
    update poll (CUPS STR #2631, LP: #177075). Thanks to Hugues Fournier
    (hugues dot fournier at gmail dot com) for the patch.

cupsys (1.3.4-4) unstable; urgency=high

  [ Kenshi Muto]
  * cupsys depends on "ghostscript | gs-esp", not "ghostscript | gsp-esp"!
    I should punish myself.
    (closes: #456455)

cupsys (1.3.4-3) unstable; urgency=high

  [ Martin Pitt ]
  * debian/control: Bump Standards-Version to 3.7.3 (no changes necessary).

  [ Till Kamppeter ]
  * debian/patches/cups-stops-broadcasting-on-hup-with-explicit-browseaddress.dpatch:
    cups stopped broadcasting on a hup signal when using a fixed
    browseaddress (cups str #2618, lp: #173470).

  [ Kenshi Muto]
  * Debconf translation
    - French (closes: #456272)
    - do update-debconfpo. Update all translations to use the msgstr 'dnssd'
      for msgid 'dnssd'.
  * cupsys depends on "ghostscript | gs-esp", to ease testing transition and
    upgrades from etch (closes: #456455).

 -- Martin Pitt <email address hidden> Wed, 02 Jan 2008 13:29:53 +0100

Changed in cupsys:
status: In Progress → Fix Released
description: updated

Till, I have updated the bug report as a preparation for an eventual SRU request, in the case you agree with it. If it satisfies you, the only thing still missing is the subscription of the SRU team . Thank you.

Till Kamppeter (till-kamppeter) wrote :

Hugues Fournier, great work! You have done a complete and correct SRU request. Please consider applying for getting a MOTU!

I have subscribed this bug to the SRU team for further processing now. Please be patient, it can take some time until the SRU completes, as on CUPS some other SRUs have queued up. Perhaps we will need an updated of the debdiff from you applied on the last CUPS update.

Martin Pitt (pitti) wrote :

Thanks a lot Hugues! I uploaded your gutsy SRU with some changelog tweak to point out the impact (so that normal users can understand why they want to install it) and to put you as uploader, since you prepared the entire diff.

Please test the binaries in -proposed to verify that everything built correctly and give feedback here, so that the package can move to -updates eventually.

Changed in cupsys:
status: New → Fix Committed

Thank you Till and Martin!

A brief report after some days of testing on i386 as well as on powerpc and amd64:
- As expected, TEST CASE is verified on each of these arches
- In some real life usage with OpenVPN interfaces, sharing is available and authorized a few dozen seconds after interface is turned up on the server, whatever be the version of the client.
- No surprising crash during these last 5 days.

( I took the opportunity to also test (with success) the HUP signal behaviour related to bug 173470 (1.3.2-1ubuntu7.4) on all these 3 arches )

Martin Pitt (pitti) wrote :

Hugues, thank you for the extensive testing and the feedback! Considering verified.

Martin Pitt (pitti) wrote :

Copied to gutsy-updates.

Changed in cupsys:
status: Fix Committed → Fix Released
dino99 (9d9) on 2012-08-31
affects: cupsys (Debian) → cups (Debian)
Changed in cups (Debian):
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers