Description of problem: | Case Information | --------------------------------------- Case Title : cups client log fills up rapidly Case Number : 1589030 Case Open Date : 25-JUN-2007 Version-Release number of selected component (if applicable): cups-1.1.17-13.3.43 How reproducible: 100% if BrowsePoll is turned on. Steps to Reproduce: 1. Set up a cups server 2. Set up client to use BrowsePoll 3. Watch logs fill up The problem is with cups-polling.patch + fprintf(stderr, "DEBUG: %s found %d %s.\n", prefix, max_count, + op == CUPS_GET_PRINTERS ? "printers" : "classes"); + + type, state, uri, location, info, make_model); + + fprintf(stderr, "DEBUG2: %s Sending %s", prefix, packet); These do not look like they have been properly 'wrapped' so that log levels are being used. This causes the logs to fill up as long as logs are active.
+ fprintf(stderr, "DEBUG: %s found %d %s.\n", prefix, max_count, + op == CUPS_GET_PRINTERS ? "printers" : "classes"); This includes a newline at the end of the text. + fprintf(stderr, "DEBUG2: %s Sending %s", prefix, packet); Here, 'packet' ends in a newline (see the snprintf statement directly above that line): snprintf(packet, sizeof(packet), "%x %x %s \"%s\" \"%s\" \"%s\"\n", What does this say?: grep ^LogLevel /etc/cups/cupsd.conf
grep ^LogLevel /etc/cups/cupsd.conf LogLevel info E [03/Jul/2007:12:33:09 -0600] DEBUG2: [cups-polld 64.106.76.106:631] Sending 3 3 ipp://print2.unm.edu:631/classes/ljea3 "ESC 108" "ESC 108" "Local Printer Class" E [03/Jul/2007:12:33:09 -0600] DEBUG2: [cups-polld 129.24.9.40:631] Sending 3 3 ipp://print.unm.edu:631/classes/ljea3 "ESC 108" "ESC 108" "Local Printer Class" We get tons of these every minute. The only way we could get it off was to set LogLevel 0
Oh dear, sorry. :-( Indeed, UpdatePolling() in dirsvc.c from cupsd does this to messages from cups-polld: LogMessage(L_ERROR, "%s", buffer); The fix would be to remove the cups-polld debug messages altogether. Stephen, did you say you had filed a support request for this issue?
Yes... it is listed as 1589030. Its funny that I think my other bugzilla helped cause this problem :).
Ok I am going to ask that this be moved to a security problem. Server had cups turned on and filled up logs. We were then unable to get the logs of the people who later broke into the server.
I'm most interested in how a remote attacker used CUPS to break into a server. We are not aware of any outstanding flaws in CUPS that could lead to this outcome. Did you preserve an image of this machine by chance? I'm not willing to call this a security bug given there are countless ways to fill up server log files. A diligent admin should keep an eye on things like disk space. If you think I'm missing something here, please do let me know.
Sorry.. the break in was unrelated to cups... but cups made it impossible to figure out what was going on the system. The breakin probably occurred due to bad password. However all the logging programs were not able to say what/who did it. The issue is that currently if you have cups turned on with browsepoll, it can fill up a gig in a day or two due to this BUG in it. Box was built on Friday, box was broken into over weekend, and all I have is a couple hundred megs of cups logs.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHSA-2008-0153.html