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
