Description of problem:

By default, it appears to extract gzipped archives into a working dir in
/var/cache/logwatch/. Which has a high potential to blow up the /var volume if,
for example, apache is a high-volume site and the logs are already rotated and
zipped in order to prevent just such a problem. :-/

Even worse, when logwatch blows up /var and dies, it leaves all the temp junk
behind so what would have been a brief blowup of space on /var instead is a
permanent disk full error requiring manual intervention.

Version-Release number of selected component (if applicable):
This was verified on v7.0, but a brief inspection of the v7.2 update does not
indicate that this issue was addressed.

How reproducible:

Roll out high-volume apache server with logwatch installed. Setup a logrotate
policy as needed for faster rotation and compression. Watch closely at 04:04
logwatch consume growingly huge amounts of space as it expands the compressed
logfiles. If it every fills up /var, BANG it will leave behind its mess and a
full volume.
  
Expected results:

#1 required: it should die gracefully and clean up its mess
#2 optional: some sort of sanity check before going to town on compressed huge
archive files