Bug 1411843
| Summary: | pdf2dsc error: invalidaccess --.locksafe-- | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | anecdote <john.macmahon> | ||||
| Component: | ghostscript | Assignee: | David Kaspar // Dee'Kej <deekej> | ||||
| Status: | CLOSED NOTABUG | QA Contact: | QE Internationalization Bugs <qe-i18n-bugs> | ||||
| Severity: | low | Docs Contact: | Lucie Vařáková <lmanasko> | ||||
| Priority: | unspecified | ||||||
| Version: | 6.8 | CC: | kent, lmanasko | ||||
| Target Milestone: | rc | ||||||
| Target Release: | --- | ||||||
| Hardware: | x86_64 | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Known Issue | |||||
| Doc Text: |
A *.dsc file converted from a *.pdf file by the `pdf2dsc` script cannot be opened in Evince
It is no longer possible to convert a *.pdf (Portable Document Format) file into a *.dsc (Document Structure Convention) file with the `pdf2dsc` script, and open the converted *.dsc file with the Evince GNOME document viewer, located outside the Ghostscript's sandbox. It is a result of the fixed `-dSAFER` option, which forces Ghostscript to operate in sandbox mode. For details and a workaround, see https://access.redhat.com/articles/2948831.
|
Story Points: | --- | ||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2017-02-13 12:05:51 UTC | Type: | Bug | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Bug Depends On: | 1410260 | ||||||
| Bug Blocks: | |||||||
| Attachments: |
|
||||||
|
Description
anecdote
2017-01-10 15:38:35 UTC
Hello anecdote, 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: CVE-2013-5653 CVE-2016-7977 CVE-2016-7979 CVE-2016-8602 ... 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: https://bugs.ghostscript.com/show_bug.cgi?id=697529 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. Best regards, David Thanks David, 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. Best regards, anecdote (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 > files. 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. Best regards, David Hi David, 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. Best regards, anecdote (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 > file: > > ... > -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. ;) Best regards, David The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days |