[tex-k] xdvi 22.40i status

M. Shell mshell@ece.gatech.edu
Wed, 10 Apr 2002 02:59:33 -0400


Stefan,

Thank you for the info, I understand the issue a lot better now.

As far as using TEXINPUTS goes, I will mention it in the docs. This approach
saves pool space too. However, the situation I had in mind was when authors
send me tar balls with the eps files in different directories. Reckdahl's 
graphics guide mentions that using TEXINPUTS is more portable than using 
relative paths. Textures for the Mac accepts "\" as directory separators,
but OzTeX still does not. sigh.

Another workaround is to use a 7.03 gs_init.ps file in a 7.04 installation
(with a version number that lies by reporting 7.04).

OK, I did some more digging in the Ghostscript development list archives 
and came up with some more information.

The first hint came from Russell Lang:
http://www.ghostscript.com/pipermail/gs-code-review/2002-January/001719.html


> Another test which fails because relative paths are not 
> allowed in safe mode, even if they are explicitly listed in 
> PermitFileReading.  I'm not sure that we need to fix this 
> one, I just wanted to flag it as a possibility.


To which Ray responded:
http://www.ghostscript.com/pipermail/gs-code-review/2002-January/001721.html


> Unfortunately, since checking for parent directory is platform specific,
> I just punted and disallowed parent directory references. Otherwise, if
> PermitFileReading were something safe like: [ (mydir*) ] it would be
> possible to use access a file above mydir like (mydir/../somewhere/else)
> 


Ray later wrote:
http://www.ghostscript.com/pipermail/gs-code-review/2002-January/001723.html


> I haven't changed anything to make the '..' valid. Note that this
> syntax IS valid as a command line argument.


So it would appear if this is a Ghostscript bug. Further supporting
evidence is given by:

http://www.ghostscript.com/doc/AFPL/7.04/Issues.htm#Differences_from_Adobe

which states:


> Adobe implementations often treat the filesystem as flat. This means that
> the path separator characters are not handled as special characters in
> filenames. The PLRM states that file names are implementation specific 
> (section 3.8.2) and Ghostscript currently implements filenames that conform
> with the underlying operating system as is stated in this section about the
> %os% device. This can result from behavior that is different from Adobe
> printer implementations. 


So, I opened up a bug report:
http://sourceforge.net/tracker/index.php?func=detail&aid=541856&group_id=1897&atid=101897


However, xdvi is not out of the woods yet.

Check this out:
http://www.ghostscript.com/pipermail/gs-devel/2002-March/001414.html


> We're pleased to announce the availability of a candidate tarball for 
> the AFPL 7.20 development snapshot. Please download and test

(The distro page is: http://casper.ghostscript.com/~giles/ )

> Also new in this release is that -dSAFER is now the equivalent of 
> '-dSAFER -dPARANOIDSAFER' in 7.04, limiting both read and write file 
> operations. This breaks some scripts, notably gv; they will have to 
> updated. Packagers and the driver/script/viewer authors are advised to 
> look at the new security changes including the  LockSafetyParams 
> mechanism.


Crap! Now when we call -dSAFER it will REALLY be safer alright!

Nelson Beebe then weighed in:
http://www.ghostscript.com/pipermail/gs-devel/2002-March/001418.html

> Because gv is the normal interface by which many users employ
> ghostscript for PostScript and PDF file viewing, I believe that it
> is INAPPROPRIATE to make a change of this sort without the
> SIMULTANEOUS ANNOUNCEMENT of an updated version of gv.


The problem is now what to do with xdvi. 

See, the issue they are wrestling with is the same one that concerned me
about the dvips -R ("z" in config.ps) option.

Applications like this need to default to protect unsuspecting command
line users from malicious writes - there are no dangerous reads unless the
application is suid. However, when used by a daemon, the applications may
have to allow a controlled set of writes *and* protect against malicious
reads! (Because the application may not have the same UID as the person
that asked it to run some PS code.) This latter situation will have to
involve a more complex access control mechanism (e.g., gs's PermitFile
stuff).

Changing the default behavior of an application later can be a nightmare.

If no gs options will now be -dSAFER, and -dSAFER is now -dSAFERPARANOID,
who's on third?! (Sorry, I couldn't resist this joke.)


If xdvi calls -dSAFER, then all reads will be locked out. If xdvi does
not call -dSAFER there will be a security hole when used with gs 7.04
and prior. So, we might have to have xdvi ask gs for its version number 
to know what to do in a given run.


There is good news, they are making progress on fixing the two bad bugs
in gs7.00--7.04 that can really bite LaTeX users. I think that gs may
yet take the lead over Distiller in terms of who makes the better pdf.



 Mike Shell
 mshell@ece.gatech.edu