Red Hat Bugzilla – Bug 140118
cups upgrade produces raw postcript
Last modified: 2007-11-30 17:10:55 EST
From Bugzilla Helper:
User-Agent: Opera/7.54 (X11; Linux i686; U) [en]
Description of problem:
After upgrading cups, printing fails, with raw stairstepped
postscript code printed instead of the rendered print image.
1) The /etc/cups/ppd/<printer>.ppd file is recreated with the wrong
file permissions - not world readable. I suspect the file is
generated with invalid assumptions about root's umask. BAD!
2) The /var/log/cups/error_log file fails to say anything about a
read permission error. ALSO BAD!
Version-Release number of selected component (if applicable):
cups-1.1.22-0.rc1.8 and foomatic-3.0.2-3
Steps to Reproduce:
1. upgrade cups
2. have non-root user print postscript document
Actual Results: raw postscript code prints
Expected Results: rendered postscript prints
a) the ppd file should have the permissions set explicitly, or
b) the ppd file permissions should be set to the original value, or
c) whatever parses the ppd file should have appropriate uid or gid.
2) The error_log file shows
D [19/Nov/2004:10:49:39 -0700] [Job 40] foomatic-rip version
$Revision: 126.96.36.199 $ running...
D [19/Nov/2004:10:49:39 -0700] [Job 40] Parsing PPD file ...
a) nothing - if the ppd cannot be read because of a permission error
b) D [19/Nov/2004:13:15:42 -0700] [Job 45] *cupsFilter:
"application/vnd.qcups-postscript 0 foomatic-rip"
- if the ppd file can be read.
The error_log file should show the permission error! since this is
hard enough to find by itself. Also, it is not obvious that the ppd
_has_ to have world read permission since, hey, maybe the print stuff
can read files owned by root. NOT - oops.
Those files are created by system-config-printer.
Fixed in CVS.
Fixed package is 0.6.117-1, although that package depends on the rawhide python
Please re-open if you think this is important enough to warrant an update
package for FC3.