[tex-k] xdvi 22.40i status

[M. Shell]

Stefan Ulrich wrote:
> 
> 
> Hmm, in my understanding, running gs-7.20 with -dSAFER will
> *dis*allow all reads/writes (as demonstrated by the example
> above), but running it with no argument or -dNOSAFER will allow
> *all* reads and writes, as demonstrated by the following:


You are right. I did some more digging.

Looking at:
http://www.ghostscript.com/doc/cvs/History7.htm

I seem no mention of an implied -dSAFER. I thought I had read
this somewhere, but I guess not.

Now, back in January, they were discussing the security updates and
Raph wrote:
http://www.ghostscript.com/pipermail/gs-code-review/2002-January/001755.html

> Much more troubling is the fact that gv is now broken. Here's why:
> gv invokes gs with the following command line:
> execve("/usr/local//bin/gs", ["gs", "-dNOPLATFONTS", "-sDEVICE=x11",
> "-dTextAlphaBits=4", "-dGraphicsAlphaBits=4", "-dMaxBitmap=50000000",
> "-dNOPAUSE", "-dQUIET", "-dSAFER", "-"]
> .
> .
> When we were discussing this patch, we were unsure if there were any
> users who used -DSAFER but required read access to arbitrary files.
> Now we know. Too bad it's taken until now to turn up.


Crap! They knew and went ahead with it anyway!

then he wrote:
http://www.ghostscript.com/pipermail/gs-code-review/2002-January/001756.html

> As we discussed, it's not necessary if we make -dSAFER open up
> read file permissions, but it sounds like we're going to do that
> for the GS_6_5 and GS_7_0X branches only, while in HEAD -dSAFER
> will lock down read permissions as in your current patch, and as
> -dPARANOIDSAFER will on the release branches.

then Peter wrote:
http://www.ghostscript.com/pipermail/gs-code-review/2002-January/001757.html

> For the record, I am extremely unhappy at the prospect of deliberately
> introducing subtle, command-line-visible differences between the GPL and
> AFPL branches that make it impossible to write code that will work with both
> branches.
>
> At the very least, if we do this, we must commit to keeping PARANOIDSAFER
> indefinitely with its present function, so that it is at least possible to
> make a version of gv that will work correctly with both versions (by using
> PARANOIDSAFER).

then Peter further wrote:
http://www.ghostscript.com/pipermail/gs-code-review/2002-January/001758.html

> Correction: gv will work correctly with both versions if it uses *both*
> -dSAFER *and* -dPARANOIDSAFER.  The patch that will be applied to the GPL
> branches should explicitly include a warning that the meaning of -dSAFER
> will be changing, and should instruct application writers to use *both*
> switches if they want compatibility with both branches.


Man, so, in any event, gs will be write insecure without the -dSAFER
option (so users HAVE to use -dSAFER to get write protection) and
there seems to be no (as) easy way to get the read access we currently enjoy.

What are they trying to address? Here's the start of it all.
Ray wrote in Dec 2001:
http://www.ghostscript.com/pipermail/gs-code-review/2001-December/001576.html

> Reviewers,

> As part of more general security improvements to Ghostscript, this
> first patch addresses the need to lock down the OutputFile device
> parameter. In the current released version OutputFile supports writing
> to arbitrary files even when -dSAFER is specified and there is also
> no defense to the arbitrary use of the '|' or '%pipe%' syntax.

> Unfortunately the use of OutputFile specifiers that include pipes and
> files is common in uses of Ghostscript, so the proposed changes allow
> command line invocations to have unlimited access, but allow for
> locking down the access to protect from flawed or malicious PostScript
> files.

> After discussion with Raph, Peter, Ralph and others, we have decided
> that command line specifiers of OutputFile will not be affected by the
> changes to implement improved security, thus preserving most of the
> legacy uses of ghostscript.


Then Ray later states:
http://www.ghostscript.com/pipermail/gs-code-review/2001-December/001612.html


> The implication is that GSView or other clients that wish to switch
> devices 'on the fly' will need to start Ghostscript without the
> .LockSafetyParams set. For this patch, there is no problem since the
> lock is not set as part of -dSAFER. Thus all clients will operate
> as they do now, with no change needed.

> 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.

> Note that if a single device switch is all that is needed, the 'save'
> is optional -- the key point is that the client must perform any
> device switching prior to going into SAFER mode.



I do not know a lot about Postscript, but that looks like a lot more
work than the old way.

[Note: gs policy may have changed since these were written.]



They should keep a distinction between read and write protection -
-dSAFER should be fixed to protect against the latter without
having to lock out all the reads.



 Mike