#618530 gs -dSAFER: /invalidfileaccess with "run" operator

Package:
ghostscript
Source:
ghostscript
Description:
interpreter for the PostScript language and for PDF
Submitter:
"Ralph A. Smith"
Date:
2024-01-05 02:51:07 UTC
Severity:
important
Tags:
#618530#5
Date:
2011-03-16 01:12:49 UTC
From:
To:
The behavior of the -dSAFER flag has changed between versions of Ghostscript
in Lenny and Squeeze.  It now prevents -sOutputFile from working if the
input is taken interactively or from a pipe.  For example:

user@host:path$ gs -q -dSAFER -dSAFINTERPOLATE -dTextAlphaBits=4 -dGraphicsAlphaBits=4 -sDEVICE=ppmraw -r144 -sOutputFile=foo.ppm
GS>(foo.ps) run
Error: /invalidfileaccess in --run--
Operand stack:
   (foo.ps)   (r)
...

This is annoying for those of us who use pipes in scripts to generate graphics,
say for web applications.  Google did not show any obvious accounts of this.
At the very least, it should be documented in a changelog.
#618530#10
Date:
2011-03-16 01:36:56 UTC
From:
To:
Hi Ralph,

Ralph A. Smith wrote:

Thanks for reporting.  Could you try some versions among 8.71~dfsg2-6,
8.71~dfsg2-4, 8.71~dfsg2-3, 8.70~dfsg-2.1, and 8.64~dfsg-13 from
snapshot.debian.org and let us know which ones work?

Jonathan
#618530#15
Date:
2011-03-19 18:07:07 UTC
From:
To:
Surprisingly, the invalid file access does not occur in any of the versions
you suggested, but returns when I upgrade to the current version
(8.71~dfsg2-9).  For each case, I installed ghostscript, libgs8 and
gs-common debs for the test.
#618530#20
Date:
2011-03-20 10:30:51 UTC
From:
To:
fixed 618530 ghostscript/8.71~dfsg2-6
found 618530 ghostscript/8.71~dfsg2-6.1
found 618530 ghostscript/9.01~dfsg-2
tags 618530 + confirmed
# regression
severity 618530 important
retitle 618530 gs -dSAFER: /invalidfileaccess with "run" operator
forcemerge 414002 618530
quit

Hi again,

Ralph Smith wrote:

	man -t ls >ls.1
	echo '(ls.ps) run' | ghostscript -dSAFER

fails with /invalidfileaccess, while with 8.71~dfsg2-6 it succeeds (and if
ghostscript-x is installed, renders the manpage).  This has nothing to do
with OutputFile, piped input, or relative paths --- something[1] has changed
to make innocuous _reads_ break with -dSAFER.

Michael, any hints?

Jonathan

[1] via debian/patches/1010_CVE-2010-2055.patch
#618530#43
Date:
2011-10-16 01:28:44 UTC
From:
To:
unmerge 618530
# just a regression
severity 618530 important
found 618530 ghostscript/9.04~dfsg-2
tags 618530 + upstream
forwarded 618530 http://bugs.ghostscript.com/show_bug.cgi?id=692602
quit

Jonathan Nieder wrote:

Thanks again.  Let's see what upstream says.
#618530#64
Date:
2016-07-22 11:38:40 UTC
From:
To:
NICE DAY,

 My name is Miss Angela, I pray that this letter meets you well,though we
never meet or seen each other before, but I believe that nature has a way
of bringing people together for specific purposes.If you need a friend
Email me back,
#618530#69
Date:
2024-01-05 02:32:18 UTC
From:
To:
From the referenced bug report, upstream says it is an intentional behaviour
change:

Ray Johnston 2012-02-18 22:32:06 UTC

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.