texlua-based tool and restricted shell escape

Joseph Wright joseph.wright at morningstar2.co.uk
Wed Feb 21 08:16:49 CET 2024


Hi Karl,

On 20/02/2024 22:16, Karl Berry wrote:
> Hi Joseph,
> 
>      In the notes for the upcoming TL'24 version of LuaTeX, it seems that lfs
>      functions should be able to work safely in restricted shell escape mode.
>      Is that a fair reading?
> 
> Yes. That's exactly the goal. I won't be surprised if there is some
> nefarious way to get around the protections (testers welcome), but we
> did our best. (Luigi and Marcel did all the real work; thanks, guys.)

Thanks for confirming: it's a bit hard to test ad hoc as of course I 
don't have an entry for the script in those things allowed in restricted 
shell escape just yet ... so I can only test unrestricted :) (If this 
looks like it will work, I will of course test locally.) I'm very happy 
to hear that I shouldn't need to worry at the script end, with the 
engine making sure things work properly.

>      wondering about putting together a Lua-based script that would do the
> 
> A Lua-based texosquery would be most welcome as far as I'm concerned. I
> see no problem, in principle, with including it in
> shell_escape_commands. I don't see any real difference between providing
> functionality in language X vs. language Y. (Pace memoize-extract.pl
> vs. .py ...)

Sure: it was a question of whether you feel Lua can meet the fundamental 
security requirements. To be clear, I'm not necessarily thinking of all 
of the functionality of texosquery at the moment, rather focussed ideas 
that fit in with a use case I have in mind.

> Nicola did good work with the Java texosquery, but she and I knew all
> along that Java is, as you say, "non-ideal" for portability.
> 
> Whether the equivalent of "ls" (what texosquery does) should be an
> allowed operation is another discussion. I admit I can't remember
> Nicola's argument for why it was ok to allow this, but evidently she
> convinced me :). --best, karl.

I suspect Nicola's argument for ls was the same as the use case I have. 
The question arose as a user wanted to do something that comes up from 
time to time: read all of the files of type X into a LaTeX document. 
Now, one can script that externally, but if you want a platform-neutral 
position and something 'easy' for collaborators, that's non-trivial.

So the aim is to be able to get a file listing inside the TeX run, then 
do \input or \includegraphics or whatever for the result. It's a simple 
enough idea, and if set up correctly I hope is security-safe.

I will start drafting something beyond my current bare-bones 
implementation, then.

Joseph


More information about the tex-live mailing list.