Bug 697529

Summary: 'invalidfileaccess -9' when opening converted file with evince
Product: Ghostscript Reporter: David Kaspar // Dee'Kej <deekej>
Component: PS InterpreterAssignee: Ken Sharp <ken.sharp>
Status: RESOLVED INVALID    
Severity: normal    
Priority: P4    
Version: 9.20   
Hardware: PC   
OS: Linux   
Customer: Word Size: ---
Attachments: simple PDF used to reproduce the issue

Description David Kaspar // Dee'Kej 2017-02-01 07:02:14 UTC 
Created attachment 13339 [details]
simple PDF used to reproduce the issue

Hello folks,

we received an information that after applying the patches for
> CVE-2013-5653
> CVE-2016-7977
> CVE-2016-7979
> CVE-2016-8602
in RHEL-6.8, converting a PDF with 'pdf2dsc input.pdf output.dsc' will produce a file which is no longer readable with 'evince'.

I was able to reproduce this on Fedora 25 (ghostscript-9.20) and even with latest fresh ("vanilla") build from your git repository.

Opening the output.dsc file with 'evince' in console will produce this error:
---------------------
[upstream||ghostpdl/bin] u= [master *] $ ./gs -q -dNODISPLAY -P- -dSAFER -dDELAYSAFER -sPDFname=./input.pdf -sDSCname=./output.dsc ../lib/pdf2dsc.ps -c quit

[upstream||ghostpdl/bin] u= [master *] $ evince output.dsc

(evince:15387): Gtk-WARNING **: Allocating size to EvSidebar 0x556a74284540 without calling gtk_widget_get_preferred_width/height(). How does the code know the size to allocate?
invalidfileaccess -9
invalidfileaccess -9
invalidfileaccess -9
invalidfileaccess -9
---------------------

The evince will end up stuck in endless loop while "Loading..." the contents of output.dsc.

I'm attaching the input.pdf file, so you can reproduce this yourself.

NOTE: The original reporter (https://bugzilla.redhat.com/show_bug.cgi?id=1411843) encountered different problem in RHEL-6.8. That problem (during conversion) has been fixed by applying the patch from commit below:
http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=99e331527d5

So, we're now able to convert the file successfully, but nevertheless - the problem described above arised, which is reproducible on latest version as well.
Comment 1 Ken Sharp 2017-02-01 07:23:06 UTC 
The pdf2dsc PostScript program produces a file of the form:

(input.pdf) (r) file { DELAYSAFER { .setsafe } if } stopped pop
 pdfopen begin
 process_trailer_attrs

This has several implications:

1) It will only work with Ghostscript, since it uses Ghostscript-specific PostScript extensions.

2) If you run this with -dSAFER then it will be unable to open the file 'input.pdf' (unless it is in a location specifically permitted for opening). The 'dsc' file requires you to run with -dDELAYSAFER.

I suspect that the change in behaviour is due to SAFER being fixed so that it works as expected. Which breaks this file if you run with -dSAFER.

As I said on IRC, if you want a PostScript file, use the ps2write device to create a real PostScript file which is DSC-compliant *and* works with other PostScript consumers. And doesn't require you to set -dDELAYSAFER either.

Oh, and you'll need to use something more recent than 8.70 to get DSC-compliant PostScript out of the ps2write device I think.