Bug 134237 - Possible to send CUPS into an endless loop because of no hostname sanitychecks
Possible to send CUPS into an endless loop because of no hostname sanitychecks
Status: CLOSED UPSTREAM
Product: Fedora
Classification: Fedora
Component: cups (Show other bugs)
2
All Linux
medium Severity medium
: ---
: ---
Assigned To: Tim Waugh
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-09-30 10:49 EDT by Kyrre Ness Sjøbæk
Modified: 2007-11-30 17:10 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-10-08 09:42:46 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Kyrre Ness Sjøbæk 2004-09-30 10:49:12 EDT
Situation:
Two computers: one running FC2 (kyrre), the other running
fc3t2(localhost). localhost is sharing the printer "HP2000C", and
kyrre is sharing "HP930C".

kyrre is a resolvable dns-name on the local dns-server, which points
to 192.168.0.200

localhost is also resolvable - trough /etc/hosts. This machines IP is
really 192.168.0.194

Problem:

What if we now hit "print test page" for the printer "HP2000C" on
"localhost.localdomain" on kyrre's web interface "localhost:631"? Cups
would send it to itself, and when reciving the job, send it to itself,
send it to itself... In 10 secounds i suddenly had 100 jobs in the que
for "HP2000C", and the cups web interface went very slow and
unresponsive. I dont want to know if this would go on for say, one
minute, before i shut down cups and cleared out /var/spool/cups...

Version-Release number of selected component (if applicable):
On "kyrre" (FC2):
cups-1.1.20-11.1
On "localhost":
cups-1.1.21-1.rc2.1

How reproducible:
Every time.

Steps to Reproduce:
1.Have a computer named "localhost" export a printer
2.Try to print to it
  
Actual results:
Infinite loop...

Expected results:
Cups should have detected that the domain name is not possible to
resolve back to the correct ip which the broadcast package came from -
and when it is not possible, use the ip adress instead of hostname.

Ip should have precedence over hostname.

Additional info:

Yup, the HP2000C is the one also found in this bug:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=133647

not that the bugs have anything in comon, just trying to draw some
attention to that bug as well :)
Comment 1 Tim Waugh 2004-10-08 09:42:46 EDT
Really I think this is a network misconfiguration issue.  Anyway, I've
reported it upstream:

http://www.cups.org/str.php?L934

Note You need to log in before you can comment on or make changes to this bug.