Bug#764253: system-config-printer: Creates millions of ppd symlinks

[Andreas Cadhalpun]

Hi,

I've also been bitten by this problem:
  * systemd-tmpfiles-setup.service hung like forever during boot
  * booting from a live system showed that 'ls ./tmp' hangs
  * 'ls -U ./tmp | wc -l' showed nearly 2 million files in tmp
  * 'find ./tmp -type l -delete' took several hours to delete the links

After that the system could be booted properly again.

Printing from e.g. gedit or evince causes scp-dbus-service to start 
creating these links at an insane rate, eating a lot of CPU. This 
continues until the scp-dbus-service process is killed.
After that printing doesn't create more links until the next login.

Debugging scp-dbus-service revealed that the problematic part is in 
/usr/share/system-config-printer/ppdcache.py, starting at line 136 [1]:
-------------------------------------------------------------------
     # Store an open file object, then remove the actual
     # file.  This way we don't leave temporary files
     # around.
     try:
         self._cache[name] = file (filename)
         debugprint ("%s: caching %s (fd %d) "
                     "(%s) - %s" % (self, filename,
                                    self._cache[name].fileno (),
                                    modtime, status))
         os.unlink (filename)
         self._modtimes[name] = modtime
     except IOError:
         # File disappeared?
         debugprint ("%s: file %s disappeared? Unable to cache it"
                     % (self, filename))
-------------------------------------------------------------------

Normally this opens the real file with 'file (filename)' and then 
deletes the symlink in /tmp with 'os.unlink (filename)'.

However, if an IOError occurs the symlink is not removed, because it is 
assumed to have disappeared.

But on my machine the IOError was actually due to 'Permission denied', 
while the symlink existed.

This was caused by the referenced file in /etc/cups/ppd not having 
sufficient permissions.
Every <printer>.ppd there had '-rw-r----- 1 root lp' permissions, but 
additionally there were also <printer>.ppd.0 files with the correct 
'-rw-r--r-- 1 root root' permissions.

After making these ppd files world readable again, the problem vanished:
# chmod -R o+r /etc/cups/ppd

Suspiciously the creation time of these ppd files coincides with the 
time at which cups was last triggered by a printer driver update.

Thus I think there are two bugs here:
  * cups should not create files with wrong permissions in /etc/cups/ppd
  * scp-dbus-service should not start an infinite loop creating millions
    of symlinks in /tmp just because the permissions in /etc/cups/ppd
    are wrong

Best regards,
Andreas

1: 
http://sources.debian.net/src/system-config-printer/1.4.3-4/ppdcache.py/?hl=136#L136