[gs-devel] -dSAFER, -dPARANOIDSAFER in gs7.20
stefan.ulrich at elexir.de
Thu Apr 11 10:39:32 PDT 2002
I'd like to bring up again the issue of -dSAFER and
-dPARANOIDSAFER in recent gs7.20 that has come up here several
times before (see e.g.
but of which I'm not sure what the current status is. This issue
has also recently come up on the tex-k mailing list (when talking
about xdvi(k)'s rendering of PS specials), and Mike Shell has
filed a bug report for this under
The problem is that gs7.20 (as of 2002-04-02) makes -dSAFER
equivalent to -dPARANOIDSAFER, so it forbids read and write
access to all files apart from those given at the command
line. This will break typical end-user applications such as gv or
xdvi(k) that want to forbid file writing with -dSAFER, but still
be able to send files to ghostscript at run-time e.g. via pipes.
In a previous mail to the gs-code-review list
In a future patch which will set .LockSafetyParams true (among other
things) when -dSAFER is set (which will become the default), clients
such as GSView will need to start Ghostscript with -dNOSAFER, then
establish perform a 'save' and switch to the desired device prior to
going into SAFER mode which will set .LockSafetyParams true. Device
switching can later be accomplished by restoring to that save object
and then switching devices, followed by going back into SAFER mode.
To me this doesn't really sound like a good solution, since it
shifts the responsability for a safety feature from a central
point (ghostscript) to $n$ applications that will try to
re-invent the wheel, creating a lot of maintainance problems and
possible sources for bugs.
I'm probably missing something in this picture, but I don't
understand why it was neccessary to change the meaning of -dSAFER
at all: Couldn't -dPARANOIDSAFER have been provided in addition
for programs like daemons or suid programs that also want to
forbid read access, and -dSAFER kept as forbidding only write
access to files?
More information about the gs-devel