Hi, With ghostscript-9.01~545 (Dont't search for initialization files in the current directory first, 2010-07-07), the default for SEARCH_HERE_FIRST flipped from 1 to 0. That was an excellent change, since it means that unfriendly people can no longer cause ghostscript to run arbitrary postscript code by putting their own gs_init.ps in /tmp, for example. As a side effect, though, it broke use of relative paths with the "run" operator when -dSAFER is set. If I run: man -t ls >ls.ps echo "(ls.ps) run" | gs then I get a rendering of the ls(1) manpage. On the other hand, if I run man -t ls >ls.ps echo "(ls.ps) run" | gs -dSAFER then I get Error: /invalidfileaccess in --run-- Operand stack: (ls.ps) (r) Likewise when the "run" command is inside a postscript file. So it seems that SEARCH_HERE_FIRST=0 is overshooting its mark, and applying not only to initialization files but to files run later using "run". Reproducible with ghostscript 9.04~dfsg-2 from Debian and with commit 2e92d2916a. Noticed because it was causing some existing postscript files to stop working. What do you think?
Assign to Marcos to reproduce.
Independently discovered this behavior in 8.63: with DELAYSAFER, relative paths to the run operator fail; I have to render the path to include the current working directory (which is counterintuitive, at best).
Apologies; this turns out to be certain configurations of my toolchain. What I really want is an explicit path setting for the run/file operators (thereby avoiding DELAYSAFER entirely), which I have described in RFE #692863.
It is EXACTLY the intent of SAFER mode (whether -dSAFER or -dDELAYSAFER) to inhibit a (potentially malicious) PS program from reading, executing, deleting, renaming, etc. file systems that are not explicitly identified by the invocation. Paths that are named on the command line using -I___ will be added to the "PermitFileReading" set of paths, but the CWD (i.e. '.' is NOT there with 9.01+ so if it is desired -P or -I. should be specified as an option. This (as far as I can tell from the previous discussion) is working as intended.
Documentation states that -I / -P path logic is NOT used for the run / file operators, is this no longer correct?
(In reply to comment #4) > It is EXACTLY the intent of SAFER mode (whether -dSAFER or -dDELAYSAFER) > to inhibit a (potentially malicious) PS program from reading, executing, > deleting, renaming, etc. file systems that are not explicitly identified > by the invocation. Ok. Then this is a documentation bug and a missing feature. 1. The documentation bug: gs/man/gs.1 explains: -dSAFER Disables the "deletefile" and "renamefile" operators and the ability to open files in any mode other than read-only. This strongly recommended for spoolers, conversion scripts or other sensitive environments where a badly written or malicious PostScript program code must be prevented from changing important files. which if I understand you correctly is just wrong. 2. The missing feature: it would be nice to be able to print, view, or convert existing but potentially malicious postscript files that include other postscript files. It is okay if this requires an extra switch and only allows reading files in some directories and with a .ps extension, to avoid attacks that use a remote postscript interpreter to read sensitive information.
The man page should be consistent with Use.htm.
Created attachment 8374 [details] gs.1: -dSAFER documentation updates, inspired by Use.htm Sounds like a good idea. How about this patch?
Small revision: Postscript files are conventionally referred to as "jobs" rather than "scripts" - other than that, patched committed in: http://git.ghostscript.com/?p=ghostpdl.git;a=commit;h=90e6a8 Thanks for the contribution! Chris
Created attachment 8392 [details] fix-up to use of "jobs" and "scripts" terms (In reply to comment #9) > Small revision: Postscript files are conventionally referred to as "jobs" > rather than "scripts" Thanks for explaining. In the paragraph about how to use NOSAFER, I really did mean "scripts" as in shell scripts. In the first sentence ("Restricts file operations the script can perform") you are right that it is clearer to say "jobs". Here's a fix-up, as a patch against ghostpdl master.
Patch committed. http://git.ghostscript.com/?p=ghostpdl.git;a=commit;h=867fb8 Thanks again, and sorry for my confusion.
(In reply to comment #11) No problem. Thanks for your thoughtfulness. Ciao, Jonathan