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--
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
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:
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:
Thanks for the contribution!
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.
Thanks again, and sorry for my confusion.
(In reply to comment #11)
No problem. Thanks for your thoughtfulness.