[tex-live] epstopdf.sty 2008 vs 2009

[Karl Berry]

Thanks for the second laundry list of problems with the restricted
execution feature.  I am thoroughly discouraged.

We certainly can't solve all of that now, or probably ever.  The idea of
checking for specific options to specific programs seems difficult (and
not especially secure) to me.  Having a wrapper for the ones we want
that sets up some kind of restricted mode seems like the only feasible
approach.  I'm certainly not going to attempt that now.

However, most of the programs you pointed out are not terribly important
to have, at least for our initial release of this, so I removed them
from the list:

    * etex
    * pdfluatex

I had intended to remove all the TeX programs from the list, and just
missed those.

    BTW, I still get an error calling `ulqda':
    Can't locate Digest/SHA1.pm in @INC

1) We have no influence on a (non-Windows) Perl installation, and
indeed, 2) it's an extra package that we don't include even in our
Windows Perl.  I don't know why the ulqda author chose to use it.
Anyway, I removed ulqda from the list, since clearly it is a minor
thing.  That makes the package useless without -shell-escape, but it
won't be the first time, no big deal.

    * dvips allows the execution of external commands, intended for
    * mkgrkindex because of the two argument form of function "open".
    * imgconvert/ImageMagick. Programs can be configured using
    * pygmentize?: What about the filter feature?
    * ps4pdf: It calls an unrestricted "latex", for example.
    * texindy, xindy?: What about their module feature?

Removed all those.  They'd be nice, but certainly erring on the side of
fewer programs is the best initial approach.  Maybe we can make an
rdvips one day.


The only really critical one in my mind is epstopdf, which was the whole
impetus for this feature:

    * epstopdf, epspdf, rpdfcrop must at least guess the
      ghostscript name and rpdfcrop allows many ghostscript names
      that matches a pattern.

If an attacker can install arbitrary files in various locations, let
alone make them executable, there is no security (completely independent
of our tiny feature).  They could just as well put in a new tex or
texmf.cnf (or ls).  So I surmise you are thinking of something else that
I'm too stupid to see.

If epstopdf can't be accepted, then we may as well forget about it.
    
    At least it shouldn't be possible to write arbitrary files.

How would you restrict it, and how can it possibly be implemented?
Obviously chroot is impossible.