Bug#803006: cups: floods log when trying to print to Samsung printer from remote computer
On Tue, Oct 27, 2015 at 07:39:00PM +0100, Didier 'OdyX' Raboud wrote:
> Control: tags -1 +moreinfo
>
> Hi Julian, and thanks for your bugreport,
Hi Didier, and thanks for the speedy response!
> Le dimanche, 25 octobre 2015, 23.26:07 Julian Gilbey a écrit :
> > I've flagged this as important because it could lead to a DoS attack
> > potentially. (It filled up my whole disk partition until I located
> > the source of the problem.) I am utterly bemused as to what might be
> > causing this problem....
> >
> > Situation: I have a Samsung ML-1610 printer connected to a machine
> > running Debian testing. I can print from the server with no problem.
> > However, I have tried printing to it from another Debian testing
> > machine and from an Apple MacBook running OSX 10.11, and they both end
> > up flooding the log file.
>
> Which log file ? /var/log/cups/error_log ? What disk space does this
> partition have? How big was the file when you hit the disk space limit?
Yes, /var/log/cups/error_log. The partition had about 9 GB total,
with 4 GB free. I just tried it again, with the splix driver in place
of the suld drivers. I tried to print from the MacOS machine, also
using the Splix driver. The error_log grew at the rate of about 80000
lines (!) every second, and grew about 550 MB in 2 minutes. Lots and
lots and lots of lines reading:
D [28/Oct/2015:23:36:45 +0000] [Client 31] Read: status=100
I tried printing from my other Debian testing machine, also using the
splix printer driver, and it still just produced messages in the
error_log file as in the initial report, but much more slowly (1000
lines per minute).
Bizarrely, I tried printing from a Windows machine, and it printed
fine with no problems.
> > My cupsd.conf file reads as follows, heavily based on the sample
> > configuration file:
> >
> > -----
> > # Log general information in error_log - change "warn" to "debug"
> > # for troubleshooting...
> > LogLevel debug
>
> This statement certainly doesn't help keeping the log small. :)
:) But it does give a hint as to the source of the problem.
> > Part of the very long error_log file reads as follows, showing the
> > whole of "Client 106"; this pattern is repeated again and again with
> > different client numbers. The most interesting (though perhaps
> > misleading) comment is that no authentication data is provided.
>
> This looks weird indeed. That said, can you reproduce this with only
> Debian packages (cups + printer-driver-splix configured for that
> printer) ?
Yes, that still happens.
> I'm not entirely dismissing an error from CUPS though: Steve Langasek
> reported the same bug on Ubuntu:
> https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1421252
>
> It looks like there's a weird {un-,}authentication loop happening there.
That could be. How might I go about tracking this down?
Thanks,
Julian
Reply to: