[tex-live] dvips cannot find figures

gnwiii at gmail.com gnwiii at gmail.com
Thu Dec 29 16:45:32 CET 2005


On 12/28/05, Reinhard Kotucha <reinhard.kotucha at web.de> wrote:
>
> >>>>> "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?


Some sites don't allow users to write in /tmp (they have to use $HOME/tmp)
both to avoid information leakage and the problems when some users process
fills /tmp.

If you allow [../]^N then you don't need absolute paths to get at
files above /tmp.
$ cd /tmp
$ ls -i /etc/passwd ../../../../../../etc/passwd
13075025 /etc/passwd  13075025 ../../../../../../etc/passwd

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


It is question of policy -- code that might be run on files downloaded
from the net should not be able to read sensitive files such as those in
/etc.
A mechanism that prevents '../../' from reaching the root directory
might be less problematic.

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?


History shows us many failures to imagine situations that turned out to be
security problems.  "Paranoid" configurations are for sites that aren't
willing to rely on imagination.

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.


The issues are not unique to TeX, so it may be worth looking for
examples in other packages.

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

More good points!

--
George N. White III <aa056 at chebucto.ns.ca>
Head of St. Margarets Bay, Nova Scotia
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://tug.org/pipermail/tex-live/attachments/20051229/cac021cf/attachment.htm


More information about the tex-live mailing list