Bug#826543: cupsd fails to remove job files at end of PreserveJobFiles interval

[Sergio Gelato <Sergio.Gelato@astro.su.se>]

Package: cups-daemon
Version: 1.7.5-11+deb8u1

My /var/spool/cups filled up yesterday. The reason turned out to be that
job files had not been purged for the past six days. I'm running with the
default setting for PreserveJobFiles (86400 seconds), so this is definitely
not intended behaviour.

I don't know yet how easy this is to reproduce; the fact that it only started
last Tuesday on a system that has been running this version of CUPS for months
suggests that it may not be entirely trivial to trigger.

Inspection of the source code has led to my spotting a logic flaw in
scheduler/job.c:cupsdCleanJobs(). I'm not yet 100% certain that it can
account for yesterday's incident, but it is definitely a flaw (apparently
still uncorrected in version 2.1.3-5).

The flaw is that cupsdCleanJobs() does not consistently guard against
the possibility that job->history_time==0 or job->file_time==0 when
updating JobHistoryUpdate. On the one hand there are checks like

      else if (job->file_time && job->file_time <= curtime)

and on the other hand one sees, in a different code branch,

	if (job->file_time < JobHistoryUpdate || !JobHistoryUpdate)
	  JobHistoryUpdate = job->file_time;

My impression is that job->file_time can be zero if a job's files have
already been cleaned up by remove_job_files(). That could lead to
JobHistoryUpdate being 0 on exit from cupsdCleanJobs(), thereby
unscheduling further calls to cupsdCleanJobs().

Accordingly, I'd recommend changing the latter statement to

	if (job->file_time > 0 &&
	    (job->file_time < JobHistoryUpdate || !JobHistoryUpdate))
	  JobHistoryUpdate = job->file_time;

and doing something similar to the two statements involving job->history_time.

(Aside: CUPS probably won't work very well before 1970-01-01 but I can live
with that. I'd be more concerned about INT_MAX being too small.)