desktop-packages team mailing list archive

Thread
Date

[Bug 1156398] Re: "scp-dbus-service" creates 100s of thousands symlinks to the ppd-file in "/tmp" untill the root filesystem runs out of inodes everytime I print something

To: desktop-packages@xxxxxxxxxxxxxxxxxxx
From: Till Kamppeter <1156398@xxxxxxxxxxxxxxxxxx>
Date: Thu, 30 Oct 2014 21:46:03 -0000
Reply-to: Bug 1156398 <1156398@xxxxxxxxxxxxxxxxxx>
Sender: bounces@xxxxxxxxxxxxx

** Description changed:

When I print e.g. a webpage in Firefox, shortly after the printing finished, the root filesystem is running out of available inodes.
"/tmp/" is populated with hundreds of thousands of symlinks to "/etc/cups/ppd/Hewlett-Packard-hp-LaserJet-4350.ppd" which are all named like "51465xxxxxxxx" (where x is a hexadecimal digit) and are created at a rate of aprox. 1500 new symlinks per second. The filenames are not counted up but seem to appear in random order.

During this time the process "/usr/bin/python /usr/share/system-config-
printer/scp-dbus-service.py" is using ~130% CPU.

As soon as I kill this process, no more symlinks are created.
When I wait for the inodes to run out, this process's CPU usage drops to ~7% for a few seconds before the process suddenly disapears from the process list. This indicates that all the symlinks are created by this one process.

If I delete the symlinks now and print another document, things start
over again.

---+ Furher notes
This does not happen when printing with
lpr
gv

It does happen when printing with
Firefox
Chromium
LibreOffice

An unpriviledged user could break down the system by filling up all free
inodes on the root fs, so this might be security relevant.
+
+
+ [Impact]
+
+ On an attempt to print out of an application like for example Firefox a
+ process runs crazy and does nothing than creating links in /tmp until
+ the file system runs out of inodes. If the /tmp directory is on the root
+ partition (and not a RAM disk) the system cannot create files any more
+ and on the next boot it can take hours for the system to clean up,
+ making the impression that the system is not able to boot any more.
+
+ [Test Case]
+
+ WARNING: To get your system easily back into a usable state by a siumple
+ reboot, at first configure /tmp to be on a RAM disk.
+
+ Modify the permissions of the PPD file of your print queue to remove the
+ world-readable bit:
+
+ sudo chmod o-r /etc/cups/ppd/*.ppd
+
+ Then try to print from Firefox (or another desktop application). Run the
+ "top" command and observe, scp-dbus-service will pick up 100% CPU. /tmp
+ will fill up with links quickly.
+
+ Kill the scp-dbus-service process to stop this. A quick workaround is
+ removing the executable bit of scp-dbus-service.py but this will disable
+ functionality of system-config-printer and other printer setup tools.
+
+ With the proposed package this will not happen any more. No mass
+ creation of symlinks in /tmp and no CPU hogging by scp-dbus-service.
+
+ [Regression Potential]
+
+ Lo, the patch is rather simple, erroring out correctly when the PPD file
+ is not readable to avoid an infinite loop.
+

ProblemType: Bug
DistroRelease: Ubuntu 12.10
Package: system-config-printer-common 1.3.11+20120807-0ubuntu10
ProcVersionSignature: Ubuntu 3.5.0-25.39-generic 3.5.7.4
Uname: Linux 3.5.0-25-generic x86_64
NonfreeKernelModules: openafs fglrx
ApportVersion: 2.6.1-0ubuntu10
Architecture: amd64
Date: Mon Mar 18 00:45:56 2013
Lpstat: Error: command ['lpstat', '-v'] failed with exit code 1: lpstat: Transport endpoint is not connected
MachineType: Gigabyte Technology Co., Ltd. GA-A75M-UD2H
MarkForUpload: True
PackageArchitecture: all
Papersize: letter
PpdFiles: Hewlett-Packard-hp-LaserJet-4350: HP LaserJet 4350 pcl3, hpcups 3.12.2
ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-3.5.0-25-generic root=/dev/mapper/hostname-root ro splash quiet vt.handoff=7
SourcePackage: system-config-printer
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 11/03/2011
dmi.bios.vendor: Award Software International, Inc.
dmi.bios.version: F5
dmi.board.name: GA-A75M-UD2H
dmi.board.vendor: Gigabyte Technology Co., Ltd.
dmi.chassis.type: 3
dmi.chassis.vendor: Gigabyte Technology Co., Ltd.
dmi.modalias: dmi:bvnAwardSoftwareInternational,Inc.:bvrF5:bd11/03/2011:svnGigabyteTechnologyCo.,Ltd.:pnGA-A75M-UD2H:pvr:rvnGigabyteTechnologyCo.,Ltd.:rnGA-A75M-UD2H:rvr:cvnGigabyteTechnologyCo.,Ltd.:ct3:cvr:
dmi.product.name: GA-A75M-UD2H
dmi.sys.vendor: Gigabyte Technology Co., Ltd.

--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to system-config-printer in Ubuntu.
https://bugs.launchpad.net/bugs/1156398

Title:
"scp-dbus-service" creates 100s of thousands symlinks to the ppd-file
in "/tmp" untill the root filesystem runs out of inodes everytime I
print something

Status in “system-config-printer” package in Ubuntu:
Fix Released
Status in “system-config-printer” source package in Utopic:
Triaged
Status in “system-config-printer” package in Debian:
Fix Released

Bug description:
When I print e.g. a webpage in Firefox, shortly after the printing finished, the root filesystem is running out of available inodes.
"/tmp/" is populated with hundreds of thousands of symlinks to "/etc/cups/ppd/Hewlett-Packard-hp-LaserJet-4350.ppd" which are all named like "51465xxxxxxxx" (where x is a hexadecimal digit) and are created at a rate of aprox. 1500 new symlinks per second. The filenames are not counted up but seem to appear in random order.

During this time the process "/usr/bin/python /usr/share/system-
config-printer/scp-dbus-service.py" is using ~130% CPU.

If I delete the symlinks now and print another document, things start
over again.

---+ Furher notes
This does not happen when printing with
lpr
gv

It does happen when printing with
Firefox
Chromium
LibreOffice

An unpriviledged user could break down the system by filling up all
free inodes on the root fs, so this might be security relevant.

[Impact]

On an attempt to print out of an application like for example Firefox
a process runs crazy and does nothing than creating links in /tmp
until the file system runs out of inodes. If the /tmp directory is on
the root partition (and not a RAM disk) the system cannot create files
any more and on the next boot it can take hours for the system to
clean up, making the impression that the system is not able to boot
any more.

[Test Case]

WARNING: To get your system easily back into a usable state by a
siumple reboot, at first configure /tmp to be on a RAM disk.

Modify the permissions of the PPD file of your print queue to remove
the world-readable bit:

sudo chmod o-r /etc/cups/ppd/*.ppd

Then try to print from Firefox (or another desktop application). Run
the "top" command and observe, scp-dbus-service will pick up 100% CPU.
/tmp will fill up with links quickly.

Kill the scp-dbus-service process to stop this. A quick workaround is
removing the executable bit of scp-dbus-service.py but this will
disable functionality of system-config-printer and other printer setup
tools.

With the proposed package this will not happen any more. No mass
creation of symlinks in /tmp and no CPU hogging by scp-dbus-service.

[Regression Potential]

Lo, the patch is rather simple, erroring out correctly when the PPD
file is not readable to avoid an infinite loop.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/system-config-printer/+bug/1156398/+subscriptions