Bug 230730

PS: I'm using the latest cups package from the 10.2 update tree:
cups-1.2.7-3.2.i586.rpm

Building cups from source using cups-1.2.7-3.2.src.rpm also fails!

After commenting out patch #4 (cups-1.2rc3-libwrap.patch)
in the cups spec-file:
# rpmbuild --clean -bb SPECS/cups.spec
[...]
Checking for unpackaged file(s): /usr/lib/rpm/check-files /var/tmp/cups-1.2.7-build
error: Installed (but unpackaged) file(s) found:
   /etc/dbus-1/system.d/cups.conf
   /usr/lib/php5/extensions/phpcups.so


RPM build errors:
    Installed (but unpackaged) file(s) found:
   /etc/dbus-1/system.d/cups.conf
   /usr/lib/php5/extensions/phpcups.so

(In reply to comment #0)
> After upgrading from 10.1 to 10.2, cups ceased to work as expected.

Same thing here, on an AMD64 machine.

[...]
> The only "workaround" so far is to add to following to /etc/hosts.allow:
> cupsd : ALL
> Then just a few error messages (...refused...) are logged at cupsd startup.

I've found this to work for me, in hosts.allow

cupsd: UNKNOWN : ALLOW

(I guess that the last ": ALLOW" could be omitted).

I think that the problem is due to the fact that non-TCP connections to CUPS have to pass through a TCP wrapper. The proof to this is that the problem can be exploited launching "lpq", that connects to CUPS using the local socket in /var/run/cups/cups.sock (you can check it with strace).

> So far I've found just this reference regarding this bug:
> http://www.mail-archive.com/opensuse@opensuse.org/msg20044.html

There are also some people reporting this problem on forums: http://www.suseforums.net/index.php?showtopic=28785

Yes, adding "cupsd: UNKNOWN" to /etc/hosts.allow works for me too.
Has somebody succeeded in building cups from the source-RPM without libwrap?

(In reply to comment #3)
You are right. Commentating or deleting of the "Listen /var/run/cups/cups.sock" line in /etc/cups/cupsd.conf (and cups service restart) can solve this problem. But it is workaround only, of course...

> I think that the problem is due to the fact that non-TCP connections to CUPS
> have to pass through a TCP wrapper. The proof to this is that the problem can
> be exploited launching "lpq", that connects to CUPS using the local socket in
> /var/run/cups/cups.sock (you can check it with strace).
> 

Sorry, but "cupsd: UNKNOWN : ALLOW" is not a valid tcpd line. If you specify a correct line, it works (as suggested by comment#4).

Please, read "man 5 hosts_access" for a correct syntax (hosts_access(5) is referenced by "man 8 tpcd")

(In reply to comment #6)
> Sorry, but "cupsd: UNKNOWN : ALLOW" is not a valid tcpd line. If you specify a
> correct line, it works (as suggested by comment#4).
>
> Please, read "man 5 hosts_access" for a correct syntax (hosts_access(5) is
> referenced by "man 8 tpcd")
 
Ok, that's the same for me, I just followed "man 5 hosts_options", that is referred by "man 5 hosts_access". ;-)

Besides this, I think that the fact that we should add a rule for tcpd to allow non-TCP connection is a bug. And I'm afraid that such rule could open security holes in a system.

Quoting "man 5 hosts_access":
> UNKNOWN
>              Matches  any  user  whose  name is unknown, and matches any host
>              whose name or address are unknown.  This pattern should be  used
>              with  care:  host names may be unavailable due to temporary name
>              server problems. A network address will be unavailable when  the
>              software  cannot  figure  out what type of network it is talking
>              to.

So, I think this bug should be reopened. Or am I too paranoid? :-)

"cupsd: UNKNOWN: ALLOW" _is_ valid if tcpd was built with -DPROCESS_OPTIONS as indicated in the description section of hosts_access(5).

Anyways, this bug is _not_ about access control file format!

Rather it is about cups _not_ working with a perfectly fine /etc/hosts.allow!
Therefore, as the initial reporter I do back the opinion that this is a BUG,
hereby reopening!

There is clearly a bug in the tcp wrapper patch used for cups. Without the workarounds of comment #3 or #5, cupsd would not even be usable in a network!

If this was for SSH, would you propose adding 'sshd : UNKNOWN' to /etc/hosts.allow as fix and resolve the bug? 

I've the feeling that we're at cross-purposes.

Please give a detailed description for a test setup. (I'm requesting a detailed one, because I think we talked about different things here)
Please explain also in detail, what happens, and what should happen, when you expect something different.
Thanks in advance.

Allright, here is a description of what I want to accomplish:
* install openSuSE 10.2 with cups
* by default, cupsd only listens on localhost
* I want to to listen on every interface/everywhere (we're on a private LAN) but limit connections to 192.168.64.0/24.
* Change the Listen directive in /etc/cups/cupsd.conf to 'Listen *:631'. Be sure to keep the Listen entry for the socket as this seems to cause the trouble with tcpd.
* Add 'ALL : 192.168.64.' to /etc/hosts.allow. Well, please assume that this entry was already there because (assume again, please) tcpd is already the desired method to restrict connects. It's less tedious to maintain a single file than many different application config files. If you assumed that, /etc/hosts.allow was not changed (and working fine until now, that is).
* Start cups with "rccups start" and you'll notice many errors logged as in comment #0.

Now, to summarize what we have done:
* Install cups, make it listen on all interfaces
* hosts.allow remains _unchanged_ 
* restart cups and it ceases to work

What _should_ happen: No errors about unknown clients only because cups listens on all interfaces instead just on localhost.

In my book, this is without doubt a cups bug and the reason for this bugzilla entry. Did this comment clearify the situation? 

To verify, could you tell me what you're talking about?

I thought that connections from UNKNOWN didn't get rejected, but should.

Nevertheless, please keep in mind that tcp_wrapper in cupsd is only an add-on feature, which SuSE/Novell offers, but isn't part of mainstream code. You might not rely on that in future.

Ah, I see! No, it is all about cups not working with a perfectly fine and _unchanged_ hosts.allow file after the upgrade from 10.1 to 10.2.

I'm not relying on tcpd for cups but I wanted to emphasize a likely usage scenario (which happens to work for me right now, though).

Anyways, I'm also aware that this is an add-on patch to the cups distribution. That's why I wanted to remove it by building cups from the source rpm. Unfortunately this doesn't work either, please refer to comment #2.
Does building from the source rpm work for you?

So, the tcp-wrapper add-on patch is obviously broken because all (even non-socket) connections are passed to libwrap (see comment #3).

The bug may even mount to an annoying DOS attack on the console:
Say, you're logging syslog errors to the console too using syslog-ng usertty() function to notice important stuff right away. Then your console is flooded with error messages from cups. How many? Well, lets count the errors per second:

# for sec in 25 26 27 28 29 ; do grep -c "^Jan  5 21:50:$sec banshee cupsd: warning: /etc/hosts.allow" /var/log/level/error ; done
564
635
612
563
685

That's about 600 lines per second, rendering your console unusable. Even worse, the logs only stop upon killing cups (or syslog, of course).
But even if you don't log to console, your /var/log partition will fill rather quickly...

Hello,

I have the same problem.
I would really like to see this solved.

Thanks

*** Bug 237578 has been marked as a duplicate of this bug. ***

Well, I tried it out... again and again...

The bad news is: I cannot reproduce it. :( Your descriptions lacks of some important information.
I can deny access via /etc/hosts.deny, I can grant access, and I can spawn several subprocesses via /etc/hosts.allow.
But I don't get any information into any logfile (hint: is there an additional logging configuration necessary, and this part missing in the requested  _detailed_ description?).

To verbalize it again: your configuration is far away from a default configuration, and your logging configuration seems not to be default neither, so I don't see any danger of a DOS. Keep in mind, if you configure your system to do a lot of logging, you'll get it. This is no DOS attack.

Provide me the required information to reproduce it and I'll be working on it again. So I'm asking you (or anyone else) again for providing a _detailed_ description for a test setup.

Hallo Klaus,

I think I have an unmodified default installation. I only copied my hosts.allow and hosts.deny from my old installation. Could you post your /etc/hosts.deny & /etc/hosts.allow to try those? I cannot find the original ones any more...

Danke, Thanks,
Andreas

Created attachment 114494 [details]
hosts.allow

I doubt that this file is enough for reproducing. Please have a look about my syslog-ng.conf comment

Created attachment 114495 [details]
hosts.deny

Hallo Klaus,


I did some more tests:

I started with using the files you attached and everything works fine!

A.
But, if you add the following to hosts.deny:

ALL: ALL

--> cupsd will consume all memory (1 GB), all swap (3 GB - ok I killed it when it used 2 GB swap...) 
--> BUG #1


B.
Add any faulty entry to hosts.allow, e.g. forget a new line, behind

cupsd: UNKNOWN, localhost

and cupsd will end up in an endless loop, printing, e.g. 
"cupsd: warning: /etc/hosts.allow, line 62: missing newline or line too long"
in /var/log/messages

--> BUG #2, since it should stop after printing it once (or a few times)!


C.
Problem #3:
I only get cups working with the following option in hosts.allow

cupsd: UNKNOWN, localhost

which is far too "open" in my mind for a sensitive machine directly connected to the outside world...


D.
Again using only  

cupsd: localhost

which I had in SUSE 10.1 ends in the endless loop of BUG #2, this time reporting the problem in /var/log/cupsd/error_log:
"tcp_wrappers refused connection from unknown. See /etc/hosts.allow and /etc/hosts.deny"
AND in BUG #1, i.e. cupsd consuming all my memory


That's it - hope you can reproduce the problem,

Thanks,
Andreas

I have this same problem too. Why isn't Novell jumping on this? I spent days trying to get this to work!

Klaus, here was my setup (whioch I posted months ago on the SUSEForum and got no reply until today!)

I installed 10.2. All went well until I tried to install my printer. As soon as Yast2 accessed cups, my pc went haywire. I traced it down to cupsd writing GBs of error messages!

They are all:
W [24/Dec/2006:14:31:09 -0500] tcp_wrappers refused connection from unknown. See /etc/hosts.allow and /etc/hosts.deny.

If I look in /var/log/messages, I get many messages also:
Dec 24 14:31:08 jardell cupsd: warning: /etc/hosts.deny, line 5: Unable to handle client address: unknown
Dec 24 14:31:08 jardell cupsd: warning: /etc/hosts.allow, line 62: Unable to handle client address: unknown
Dec 24 14:31:08 jardell cupsd: warning: /etc/hosts.allow, line 64: Unable to handle client address: unknown
Dec 24 14:31:08 jardell cupsd: warning: /etc/hosts.allow, line 65: Unable to handle client address: unknown
Dec 24 14:31:08 jardell cupsd: warning: /etc/hosts.allow, line 66: Unable to handle client address: unknown

When I start cupsd, I get:
I [24/Dec/2006:14:47:10 -0500] Configured for up to 100 clients.
I [24/Dec/2006:14:47:10 -0500] Allowing up to 100 client connections per host.
I [24/Dec/2006:14:47:10 -0500] Using policy "default" as the default!
I [24/Dec/2006:14:47:10 -0500] Full reload is required.
I [24/Dec/2006:14:47:10 -0500] Loaded MIME database from '/etc/cups': 36 types, 40 filters...
I [24/Dec/2006:14:47:10 -0500] Loading job cache file "/var/cache/cups/job.cache"...
I [24/Dec/2006:14:47:10 -0500] Full reload complete.
I [24/Dec/2006:14:47:10 -0500] Listening to 127.0.0.1:631 on fd 0...
I [24/Dec/2006:14:47:10 -0500] Listening to ::1:631 on fd 2...
I [24/Dec/2006:14:47:10 -0500] Listening to /var/run/cups/cups.sock on fd 3...
What is it listening to on the last two lines???

So far as I can tell, sshd is working properly with my hosts.allow and hosts.deny files:
Here they are:
hosts.deny line 5:
ALL : ALL EXCEPT 192.168.1., 127.0.0.1, LOCAL

hosts.allow (starting on line 62):
ALL : 192.168.1. : ALLOW
ALL : .mydomain.com : ALLOW
ALL : 127.0.0.1, localhost : ALLOW
cupsd : 192.168.1.10 : ALLOW
cupsd : 127.0.0.1 : ALLOW

If I comment out the line in hosts.deny, all works, so the problem is that the rules in hosts.allow are not being followed. I have tried numerous variations of the way I put in the domains, with no success.

I think cupsd is screwed up. Or am I making a bad error here?

I also turned off ipv6.

I'm asking myself, why noone is able to use the attachment functionality of bugzilla?
Providing tested files is less error-prone than citing the relevant part of files.

yes, you can attache .tar.gz files too. :-)

The more I listen to the reports, the more I get the feeling that the problem is the tcp wrapper parser and not cupsd. But I need to investigate this tomorrow.

I did not want to send my real ip addresses in the hosts files. But I did send ALL  of the non-commented files. cupsd goes into a tailspin as soon as you try to add a printer in yast2.

I do not think it is the tcp wrapper parser because sshd works properly with my hosts/allow/deny files.

ssh, cvs and subversion also work properly with my hosts/allow/deny files. Only cupsd goes crazy.

In reply to comment #17:
That hosts.allow file is empty. It contains no rules, just comments.

You need to add some rules, like
ALL : 192.168.64.

to reproduce. Also /etc/hosts.deny should just contain a single rule:
ALL : ALL

Created attachment 114933 [details]
my cupsd.conf and hosts.{allow,deny} files

I'm attaching my hosts.allow and hosts.deny files as well as my cupsd.conf. 

Please note that cups is the _only_ application that has problems with my hosts.{allow,deny} files. Therefore I guess it is _not_ a libwrap bug. tcpdchk has no problem either.

My cups config does not deviate from the standard setup that much other than cups is listing on all interfaces. In the tarball you'll find my current 10.2 cupsd.conf and the previous cupsd.conf of 10.1. 

Please note that cupsd.conf is the only file changed: 
# rpm -V cups
S.5..U.T  c /etc/cups/cupsd.conf
.....U..    /etc/cups/ppd
.M...U..    /etc/cups/ssl

In reply to comment #15:
The errors are logged by cups in /var/log/cups/error_log. This is the default logfile, I've not changed anything regarding logging. Please refer to my cupsd.conf from comment #26.

That said, please ignore anything regarding syslog. That is a custom setting, of course, and has nothing to do with this bug. I've provided the comment about the DOS attack just as an _example_ to show this bug is serious and annoying. Again, there is _no_ syslog issue!

I'm sorry but AFAIK there are no other steps to reproduce other than those already provided by comment #10. If you specfically need any other information, I'd be happy to provide. 

My configuration is actually pretty close to a default setup. Please check the changes to cupsd.conf of comment #26. 

Also, please remember that cups used to work under 10.1! But after upgrading to 10.2, using the cupsd.conf referenced above and _unchanged_ /etc/hosts.{allow,deny} files, I get lots of errors messages. However, _only_ from cupsd, not from any other program using libwrap.

In reply to comment #21:
The comment shows that cupsd seems to have only problems with the 'ALL' wildcard. Other rules are unaffected, right?

Ok. I can reproduce it partly (so far). The important hint I got, was no longer to look through the syslog files and use the cups logfiles.

The bad news is, that I've to tell you that it is _not_ possible to reduce the large number of same loglines in the cups error_log without removing the tcp wrapper functionality (or with large effort). The client repeats the connection attempt many times (because of bad network, etc.) and every attempt is logged in the file. The server has no possibility to send the client an error message  to stop this behavior (at this phase of communication). Sorry.

Warning! We already discussed this removal in the team, and it will be very likely that this happens if more errors are detected or the implementation/maintaining time takes to long: you can block via firewall functionality too.

The good news (?) is that the logfile will no grow much above the configured MaxLogSize in /etc/cups/cupsd.conf (or 1 MB as default), and then overwrites the additional logfile. --> no DOS attack.

I have an idea where the "unknown" results are coming from: cups 1.2 (new in 10.2) has the possibility to use domain sockets and therefore no internet adress is required. But I need more time to work on this. You might avoid this, if you always use the hostname instead of "localhost" for connections, e.g. by setting $CUPSSERVER. (untested) I want to test this out later.

Summarize: I didn't do any fixes, because its an intended behavior so far.

I got multiGB log files and complete disk thrashing, making the PC unusable until I turned off the cupsd, so I would call that a DOS.
 
The only cups client I have is on the machine with my server, so I do not see how this can be a network issue.

And this all was done on a clean install, with no changes to the default cupsd configuration. I only changed hosts.allow!

Removing tcp wrappers might be the best solution.

The firewall used iptables. Alas, the Yast2 firewall configuration does not allow restricting access to services by host. I think iptables can do this, so it should be in Yast2 also.

In reply to comment #29: Glad you're able to reproduce. :-)

I do not mind the number of errors logged, please do not waste any effort on this because that's just another manifestation of the bug. The best workaround to get rid of the bug (and the error logs) is from comment #3:
Comment on the 'Listen /var/run/cups/cups.sock' line.

Regarding tcpd:
Access control can be done in cupsd.conf alone (just as for e.g. apache), so libwrap is definitely nice to have but not a requirement. Since 10.2, cups ships with a secure default (only listens on localhost), so anyone who wants to grant more access has to edit cupsd.conf anyways.

Did the libwrap patch change from 10.1 to 10.2? My suspicion grows that the patch is not compatible with domain sockets introduced with cups 1.2.

s/Comment on the/Comment out the/

As I'm still unable to reproduce the second part, I need some debug information from outside.
- stop cups daemon: rccups stop
- Please install appropriate debug package from http://software.opensuse.org/download/home:/kssingvo/openSUSE_10.2/repodata/repoview/cups-0-1.2.7-16.1.html
- remove old logfiles: rm /var/log/cups/error_log*
- start cups daemon: rccups start
- do such an request
- attache me the logfile /var/log/cups/error_log (Note: I'm only interested in lines containing "tcp_w"[...], but you can provide me full logfile too)

Thanks in advance.

an updated version is avail. the above URL is no longer valid, please use http://software.opensuse.org/download/home:/kssingvo/openSUSE_10.2/repodata/repoview/ instead, and search for the cups-<<something>>.html file to continue with.

Good news: The bug is gone with updated cups-1.2.7-18.1.i586.rpm from the URL of comment #34. There is just one small exception

To verify, I degraded back to 10.2 update package cups-1.2.7-3.3.i586.rpm and the bug was reproducible again then.

So, I'd say cups-1.2.7-18.1.i586.rpm fixes this bug! :-)
What did you change?

Committed too early! ;-)
The exception is a syslog message:
python: [22286] error: Unable to set locale.

Logged every time right after 'Started "/usr/lib/cups/daemon/cups-deviced"' shows in /var/log/cups/error.log.

However, this is just informative! Glad this bug is fixed.

Can somebody else confirm that cups-1.2.7-18.1.i586.rpm is working for him too?
The bug could then be closed as fixed.

Sorry, what?!?
Just because you see a result in a test environment, it doesn't mean, that I finished it. Nobody else then the bug assignee should set the bug to fix.

I've not written that I (or somebody else but you) will mark the bug as fixed. Rather, I'd like other people to test the packages from comment #34 and report back to have more feedback (not just mine).

Or do you refer to the last sentence of comment #36? 
Well, perhaps I was a bit too excited back then...

However, if others confirm that the package works for them too, we could agree that you resolve this bug as fixed, right?

We still do not know what you changed in the new RPMs, though.

I got here via Bug 237578.  It seems my issue is still not solved.  I've completed an update via Yast, and noticed some cups related updates.  Some points:

Starting Jan 26 2007 I find (using ksystemlog) in the cups log (not the cups web log):
01/26/07 19:10:09	Unable to open listen socket for address ::1:631 - Address family not supported by protocol.

This error seems to be generated on boot or when one runs 'service cups start'

I don't seem to be able to get kfmclient to access cups (i.e. using the "Manage Printing" menu item in opensuse 10.2), it complains "Could not connect to http://localhost:631".  this is true regardless of the following, i.e. the Suse 'Manage Printing' menu item always fails to open the cups page.  This may or maynot be related to the following.

I am able to get firefox (Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.2pre) Gecko/20061023 SUSE/2.0.0.1-0.1 Firefox/2.0.0.2pre) to access cups via http://localhost:631
I can browse the various pages, 'Jobs', 'printers', 'administration'
 This is true only if
hosts.deny is empty
host.allow contains only:
  cupsd : 127.0.0.0\8 : ALLOW

If instead I add to hosts.deny:
ALL : ALL

Then the following behavior is observed:
 - Still using firefox, type in the url field: http://localhost:631/<enter>
 - The cups frontpage loads, there are no errors in the cups log.
 - Press the reload current page button in firefox and the cups page is replaced with a page indicating "The connection was reset: The connection to the server was reset while the page was loading."
 - In the cups error log file I see:
02/08/07 10:47:52	tcp_wrappers refused connection from localhost. See /etc/hosts.allow and /etc/hosts.deny.
 - Retype the url 'http://localhost:631/' into firefox, hit enter and the cups page loads, no errors logged.
 - Select any of the pages linked, i.e. 'Jobs', 'printers', 'administration' and the cups error log file shows the error:
02/08/07 10:52:45	tcp_wrappers refused connection from localhost. See /etc/hosts.allow and /etc/hosts.deny.

Note:  the tcp_wrappers errors appear just once each time a page is selected/refreshed, i.e. I don't seem to observe the DOS type behavior others refer to.

I hope this helps?

Mark, the fix is not yet in the Yast repositories. Did you install the cupsd in #34? That worked for me.

Hi, Apologies for the delay.  I've installed (via YaST) the cups rmp linked to in comment #34.  Essentially I see the same behavior I describe in comment #40.  One difference is that the cups error log now contains one extra line before the tcp_wrapper line mentione in comment #40.  Specifically, I now see the following pairs):

02/13/07 21:04:08	tcp_wrapper debug: lis->address.addr.sa_family == >2<
02/13/07 21:04:08	tcp_wrappers refused connection from localhost/127.0.0.1. See /etc/hosts.allow and /etc/hosts.deny.

Given no-one else seems to experience this behavior, this maybe a separate bug?  Should it be moved? 

Hope this helps...?

Mark Van De Vyver: regarding comment#40
You don't want we to comment such an obvious configuration issue at your side, don't you? :-)

Fixed package submitted to STABLE
A new version with more fixed issues should appear on openSUSE build service soon (build is triggered).

Apologies... I'm two months into linux - from pure winxp background.  I assume the obvious configuration mistake was using "\" rather than "/".  Anyway, fixing this allows firefox to work fine (i.e. with hosts.deny-> ALL : ALL).  the Manage Printing/kfmclient still errors out:
"Could not connect to host http://localhost:631/"
But this is a separate issue and should be logged as a separate report - correct?

*** Bug 276981 has been marked as a duplicate of this bug. ***