[tex-live] dvips cannot find figures

[Reinhard Kotucha]

>>>>> "George" ==   <gnwiii at gmail.com> writes:

  > If you block absolute paths then you have to block relative paths
  > like [../]^N for N larger than the current depth, since those are
  > effectively the same as absolute paths.  

They are similar, but not equivalent.  If absolute paths are
disallowed, what can be damaged if you "cd /tmp" before you execute
anything?

  > Where security is concerned, simplicity is an advantage,

That's true.  And it is helpful when similar programs behave similar
(regarding configuration), see below. 

  > so I don't see a reason to change from the current behaviour.

Again, see below.

  >> I still have to make that change to dvips, but I will when we
  >> have moved away from p4.
  >> 
  >> Unless of course everybody else thinks this is a bad idea.

  > I think it is a bad idea, but then I tend to think dvi-anything
  > that requires maintenance is a bad idea.  I hardly ever use dvi
  > anymore except to track down other people's problems.  If we make
  > dvips secure enough so it can't do anything useful then people
  > will stop bothering me.

  > My pdftex-1.30.5 handles images with absolute paths -- is there a
  > mechanism to block absolute and upwards relative paths in pdftex?

  > Time might be better spent considering how to deal with absolute
  > paths in pdftex and/or improving the documentation.

Why doesn't dvips use openin_any from texmf.cnf?   
______________________________________________________________________
% Allow TeX \openin, \openout, or \input on filenames starting with `.'
% (e.g., .rhosts) or outside the current tree (e.g., /etc/passwd)?
% a (any)        : any file can be opened.
% r (restricted) : disallow opening "dotfiles".
% p (paranoid)   : as 'r' and disallow going to parent directories, and
%                  restrict absolute paths to be under $TEXMFOUTPUT.
openout_any = p
openin_any = a
______________________________________________________________________

I do not see a good reason why dvips cannot use them.  They can be
overwritten on the command line.  The default values in tetex and TL
are quite reasonable.  I then suggest *not* to set the z-option in any
config.* file.  Then graphics inclusion in pdftex and dvips will have
the same restrictions and there is only one place where this has to be
configured. 

Karl, your suggestion

  > 0) anything goes;
  > 1) absolute/relative paths ok, shell escapes not ok;
  > 2) nothing ok.

is very similar to what we already have for *tex.

BTW., shell escapes had been removed from dvips some time ago.
libgz is now compiled into the binary so that dvips still can include
compressed graphic files.  No security problems are to be expected
here.

Hans, I do not see any advantage for something like parentlevel=2.
People might set this variable to a reasonable value and then forget
that this variable exists.  But most people will not be aware if this
and then wonder why ../../graphics/blabla/ works but
../../../graphics/blabla/ fails.  And people do not care about the
directory where they execute files.  I vote for not implementing this
variable to keep things simple. 

I do not see any big security problems with dvips at all:  The user
decides where dvips output goes.  This cannot be specified in a dvi
file.

For input files this is a bit more difficult, a PostScript file can
have arbitrary PostScript code inside which allows reading and
creating arbitrary files.  But this code is not executed by dvips.
The security settings in ghostscript are quite restrictive and I
suppose that you cannot destroy anything if you try to open a file in
a printer.

It does not matter very much from which directory an included graphic
file comes.  A bit more has to be done to make an included graphic
harmful.  Only if you provide a PS header which redefines the graphic
file inclusion code in dvips, then you can probably make something
like \includegraphics{/etc/passwd} work.  And you also have to
redefine \includegraphics so that it doesn't insist on having a
%%BoundingBox comment in /etc/passwd.  Good luck!

It is much easier to insert malicious PS code into the graphics file.
But this cannot be prevented by dvips.  This code has to be executed
by a PS interpreter.

However, if you are still concerned about security issues, what has to
be done to make things absolutely secure?

A few years ago I was wondering what can be done with Type1 fonts.
Did you know that you can add a PostScript SPECIAL to a virtual font
which contains arbitrary PS code, i.e. which creates an arbitrary file
when this font is processed by a PS interpreter?  I did this
successfully.  Well, you explicitly have to use the -dNOSAFER option
in ghostscript.  Otherwise, all you'll get is an error message.

I tried this many years ago and all I can tell is that gs had been
absolutely secure at this time.  Today, gs developers are much more
paranoid, which is somtimes a bit annoying.

Can anyone imagine a situation where dvips is a security problem
rather than the PS interpreter?

What do you think about using the value of openin_any as a default and
removing all variables which provide such restrictions from dvips'
config.* files (if necessary)?  Users can add them if necessary,
though I don't know a good reason.

George's statement "simplicity is an advantage" is not only true if we
talk about security.  If similar programs can be configured the same
way or can even share the same variables in the config file, it is
easier for users to understand how the system works, and it is of
course easier to maintain the documentation.

Another thing is confusing:

dvips looks for a file ${HOME}/.dvipsrc

We have now $TEXMFHOME in all web2c based distributions and I think
that dvips should look there instead.  It should be sufficient to set
the variable $DVIPSRC properly in texmf.cnf (see page 16 in the dvips
manual).  It is highly desirable if this file will not be hidden,
i.e. it's name doesn't start with a dot.

Regards,
  Reinhard

-- 
----------------------------------------------------------------------------
Reinhard Kotucha			              Phone: +49-511-4592165
Marschnerstr. 25
D-30167 Hannover	                      mailto:reinhard.kotucha at web.de
----------------------------------------------------------------------------
Microsoft isn't the answer. Microsoft is the question, and the answer is NO.
----------------------------------------------------------------------------