[tex-live] running tex and lua under restricted shell escape

[David Carlisle]

On 11 February 2016 at 23:26, Karl Berry <karl at freefriends.org> wrote:
>     How feasible would it  be to allow *tex and texlua to run under
>     restricted shell escape?
>
> The problems I thought of (and put in texmf.cnf comments)

Oh so you did, sorry:-)
Funny thing was I was reading those comments just the other day in a
different context but didn't come to mind when I  was musing about
this this morning.

> back when we
> created --shell-escape were that a) the --shell-escape option itself
> must be disabled, and b) openout_any must be forced to "p", even if the
> openout_any value for the top level tex is something else.  openin_any
> should probably also be p.

ug so you would (certainly disabling --shell-escape)

>
> And ... do I want to create new rENGINE binaries for (m)any values of
> ENGINE, with all the concomitant pain and confusion?  Not at all ...

No. New binaries wasn't what I had in mind, so just "no" is OK:-)

>
> Beyond that, for Lua specifically, although I know that Lua was designed
> to be a secure embedded language, it would take a lot of effort to
> research and disable possible "exploits" in such a context.  For
> starters, obviously dynamic library loading must be disabled, arbitrary
> file reading/writing, and who knows what else (not me)...

If it weren't for the possibility of passing a comandline option to
the restricted call (which I'm happy to accept kills the idea)
wouldn't the issues with libraries and file writing be just the same as
a top level lualatex call? ie the internal call wouldn't be able to write
or load libraries that a direct call to luatex could do?

>
> If the practical goal is to use luatex features in other tex's, maybe
> some crippled form of texlua, specifically, could be created (not by me)
> and allowed.

Not sure I had a _practical_ goal, was just musing on possibilities;-)

>  But is that useful enough to be worth the trouble?  If
> nothing else, the performance would be pretty awful, even on today's
> machine, even given everything, so couldn't use it in even moderately
> intensive contexts, I suspect.
>
> ?

certainly it's not worth going to any trouble. It's always possible to test
any such idea using a top level --shell-escape, and if there are practical
applications and timing isn't too bad either just live with needing the flag
or look then if there is a safe configuration that could be used.

>
> Best,
> Karl

thanks for the thoughts,

David