Red Hat Bugzilla – Bug 1411843
pdf2dsc error: invalidaccess --.locksafe--
Last modified: 2017-03-21 10:42:08 EDT
Created attachment 1239145 [details]
This is the input.pdf used in step 1.
Description of problem:
The command executed in shell environment
pdf2dsc input.pdf output.dsc
will generate an empty output.dsc and an error message of invalid access to --.locksafe--.
Version-Release number of selected component (if applicable):
pdflatex version 3.14159265-2.6-1.40.15. (TeX Live 2014)
every time using the same command in any directory
Steps to Reproduce:
1. I'll provide the file input.pdf which was generated by AUCTeX 11.86 on emacs 23.2 for a region of tex file. But I think virtually any pdf file can reproduce this error.
2. Execute the command
pdf2dsc input.pdf output.dsc
in bash environment.
The command generates the following error message:
Error: /invalidaccess in --.locksafe--
true --nostringval-- --dict:1152/1684(ro)(G)-- getenv --nostringval--
%interp_exit .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- --nostringval-- --nostringval-- false 1 %stopped_push 1862 1 3 %oparray_pop 1861 1 3 %oparray_pop 1845 1 3 %oparray_pop 1739 1 3 %oparray_pop --nostringval-- %errorexec_pop .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- 1870 0 3 %oparray_pop 1869 0 3 %oparray_pop --nostringval--
--dict:1152/1684(ro)(G)-- --dict:0/20(G)-- --dict:72/200(L)--
Current allocation mode is local
Current file position is 2063
GPL Ghostscript 8.70: Unrecoverable error, exit code 1
The command should produce a legitimate dsc file that can be further converted to png file using the following command
gs -sDEVICE=png16m -o output.png output.dsc
Since this step was done by AUCTeX package, I was not aware of the output for successful execution.
The working environment is Scientific Linux 6.8(Cartoon). I'm directed here to report the bug. This problem was encountered when using AUCTeX 11.86 on emacs 23.2. I use preview-latex package within to preview equations. When selecting equations, preview-latex executed the job successfully, but AUCTeX failed at the stage of inserting png images to emacs buffer. pdf2dsc is an intermediate tool to convert pdf to dsc and then gs will convert dsc to png so that the latter can be inserted and displayed in emacs.
The output of AUCTeX in emacs is
Preview-LaTeX exited as expected with code 1 at Sun Jan 8 12:14:19
Running `Preview-PDF2DSC' with ``gs -sDEVICE=ps2write -o _region_.prv/tmp19812cJl/preview.dsc _region_.pdf''
GPL Ghostscript 8.70 (2009-07-31)
Copyright (C) 2009 Artifex Software, Inc. All rights reserved.
This software comes with NO WARRANTY: see the file PUBLIC for details.
Processing pages 1 through 1.
Preview-PDF2DSC finished at Sun Jan 8 12:14:19
Running `Preview-Ghostscript' with ``gs -dOutputFile\=\(_region_.prv/tmp19812cJl/pr1-\%d.png\) -q -dNOSAFER -dNOPAUSE -DNOPLATFONTS -dPrinted -dTextAlphaBits\=4 -dGraphicsAlphaBits\=4 -sDEVICE\=png16m -r200.255x200.074''
Ghostscript filter: Args out of range: [(1 102368)], 1
This bug appeared on my desktop on Jan 7. A likely cause could be the recent SL security update on ghostscript
this BZ depends on BZ #1410260, which will fix the issue you have reported (thanks for that).
Unfortunately for you, the thing you're trying to do will still not work. I have been discussing the issue with upstream, and here's the sum up:
*) We are using -dSAFER option for every ghostscript invocation in the ghostscript's auxiliary scripts, to name e.g. 'ps2pdf', 'pdf2dsc', etc.
There are ways for an attacker to write malicious file (interpreted by ghostscript) that could potentionally cause harm to your system, or could gain control of it.
By using the -dSAFER option, we are telling ghostscript to operate in sandbox. If the interpretation of the input file would result in accessing the system outside this sandbox, ghostscript will fail with an error.
0) Before we issued the RHSA for:
... the 'pdf2dsc' was working for you and others, because the -dSAFER option was broken, and was not doing what it were suppose to do.
1) The release of the RHSA caused one regression, which is described in BZ #1410260, which should be fixed in next release of RHEL-6. This is what is causing the error you reported.
2) After the regression in BZ #1410260 is fixed, the -dSAFER will start working properly, and you will no longer see the error you described in this BZ.
However, you will see another error insted:
> invalidfileaccess -9
Here is the upstream bug report I created for it:
3) During the discussion with upstream, I have learned several things:
* 'pdf2dsc' is not a supported program by Artifex company, it's hackish script, and they are not sure about its future
* 'pdf2dsc' comes from lib/ folder of ghostscript source code. Content of lib/ folder isn't truly part of Ghostscript according to upstream, thea are just potentionally useful extras, but nobody guarantees they will work correctly.
* the actual way the 'pdf2dsc' works is that it will turn your original PDF into "fake/hacky" Postscript (according to upstream). The output .dsc file will contain some similar line to:
> (input.pdf) (r) file
* the 'pdf2dsc' will output is pseudo Postscript file which direct Ghostscript to read original PDF, and decorate it with DSC (Document Structure Convention). In other words, you will still need your original (input) PDF to be able to open the output.dsc file
4) There's nothing else we can do about this, except providing a suggestion to workaround this:
* avoid using 'pdf2dsc' everywhere
* evince generally reads PDFs without a problem. If you do not need it for specific reasons, keep opening the original PDFs as they are.
* if you need to convert the PDF into Postscript file, then convert it with 'ps2write' device:
> gs -dSAFER -sDEVICE=ps2write -sOutputFile=output.ps input.pdf
Or better, you can use already prepared script ('man pdf2ps' for more info):
> pdf2ps input.pdf [output.ps]
I hope this will help you.
In the meantime of submitting this bug, I also upgraded Ghostscript to 9.20 and and AuCTeX to 11.89. And pdf2dsc can now successfully generate dsc files.
But it as you mentioned, pdf2dsc is not officially supported( and presumably not safe ), this is only a workaround for whoever badly need it to work.
(In reply to anecdote from comment #3)
> In the meantime of submitting this bug, I also upgraded Ghostscript to 9.20
> and and AuCTeX to 11.89. And pdf2dsc can now successfully generate dsc
Please note that it will not be a "clean" .dsc file. It will be "fake/hacky" Postscript file decorated by DSC and telling Ghostscript to open the original PDF.
According to upstream, it will not be portable - i.e. you will not be able to open it in some other Postscript interpreter.
And it also has one more caveat, as I said before - you will have to distribute the original input.pdf with the generated .dsc file AFAIK. Otherwise, it will actually not have anything to open/display.
Upstream is discouraging in the use of 'pdf2dsc', unless you really need it and you know what you are doing, and I agree with it.
Also, please note that upstream was discussing in changing the behaviour of 'pdf2dsc' in the future, to generate clean Postscript files that could be portable. However, this change is not part of 9.20 release. It might make it in 9.21, but there's no guarantee for that.
> But it as you mentioned, pdf2dsc is not officially supported( and presumably
> not safe ), this is only a workaround for whoever badly need it to work.
Well, what surprises me is it works suddenly for you now after your upgrade to ghostscript-9.20... Unless something changed in the way you have produced your PDF, it shouldn't work.
If the original input.pdf is still the same, and you are now able to display its content after conversion without a problem, I would be afraid you are somehow no longer using -dSAFER option, which is definitely *not secure* to do so.
I just tested the pdf2dsc command. It turns out you are right: although there is no error in executing pdf2dsc, evince was not able to render the generated dsc file, it constantly shows "loading"
What I actually meant was that AucTeX was able to produce preview in emacs. Specifically, the next command
gs -sDEVICE=png16m -o output.png output.dsc
can generate png file can be displayed on evince. That's all I need.
FYI, the 11.89 AucTeX use the following preview commands for the input pdf file:
TeX Output exited as expected with code 1 at Wed Feb 8 22:17:20
Running `Preview-PDF2DSC' with ``pdf2dsc _region_.pdf _region_.prv/tmp28870ZgJ/preview.dsc''
Preview-PDF2DSC finished at Wed Feb 8 22:17:20
Running `Preview-Ghostscript' with ``/software/texlive-2014/bin/x86_64-linux/rungs -dOutputFile\=\(_region_.prv/tmp28870ZgJ/pr1-\%d.png\) -q -dNOSAFER -dNOPAUSE -DNOPLATFONTS -dPrinted -dTextAlphaBits\=4 -dGraphicsAlphaBits\=4 -sDEVICE\=png16m -r200.255x200.074''
Preview-Ghostscript finished at Wed Feb 8 22:17:20
Fortunately, I don't need portability in this case. All I want is to preview latex generated formula in emacs such that do not need to switch to another window to check the output. These files are temporary and will be discarded once I close emacs.
Since the AucTeX package chooses to use the hacky tool, I don't assume it's a terrible problem for me.
Thanks for pointing out the issue.
(In reply to anecdote from comment #5)
> I just tested the pdf2dsc command. It turns out you are right: although
> there is no error in executing pdf2dsc, evince was not able to render the
> generated dsc file, it constantly shows "loading"
Yes, that's what I meant... :) If you would do 'evince output.dsc' in console, you would see the error I mentioned above:
>> invalidfileaccess -9
> Specifically, the next command
> gs -sDEVICE=png16m -o output.png output.dsc
> can generate png file can be displayed on evince. That's all I need.
I see. I'm not sure what the 'png16m' ghostscript's device do. However, the command is not using '-dSAFER' option. I guess it's OK for input files you have created by yourself and you know theirs content.
But it's really *not safe* to run this command for files download from web... ;)
> FYI, the 11.89 AucTeX use the following preview commands for the input pdf
> -dOutputFile\=\(_region_.prv/tmp28870ZgJ/pr1-\%d.png\) -q -dNOSAFER
So, actually AucTeX uses here -dNOSAFER. It explicitly bypasses the '-dSAFER' option, thus it's able to display your generated file. For files you trust it is okay. In other cases I can only advice caution. ;)