I would avoid modifying the list of programs allowed to run in the restricted shell. These are either programs that don't write out any output (and when output redirection is requested they don't work in the restricted shell escape setting) or respect the openout_any setting in texmf.cnf.
As far as the present problem is concerned, running pdflatex with shell escape enabled on the file filename.tex consists in using the command line
pdflatex -shell-escape filename
(no quotes).
How to setup a front-end to run this command depends on the front-end itself. With TeXShop, for example, one can define a new engine. In your ~/Library/TeXShop/Engines folder duplicate XeLaTeX.engine and call it pdflatexshell.engine. Modify the file (with TeXShop itself) to read
#!/bin/tcsh
set path= (/usr/texbin /usr/local/bin $path)
pdflatex -shell-escape "$1"
and, for a file you want to compile with unrestricted shell escape, write at its beginning
% !TEX TS-program = pdflatexshell
so that the engine will be automatically selected on opening.
What to do with other front-ends or LyX will vary.
If you really want to use the restricted shell escape, you have to enable
uname
rm
echo
latex
The program list can be determined by searching for runsystem in the .log file.
I think my answer will be totally biased, but here it goes. :)
It's quite subjective for me to afirm that arara is safe or secure. It's just a program with a specific purpose, just like most of the tools available out there. Maybe the best answer I can come up with is: it depends.
arara per se simply expands directives into commands through rules that specify the way this expansion shoud happen. Commands are then delegated to the underlying operating system.
The program requires a valid directive (mapped to a rule) in order to run, otherwise the process stops.
Uh-oh, I could not find the 'foo' rule in the search path. Could
you take a look if the rule name is correct and if the rule is
accessible through the search path?
If there are no directives, arara will also complain.
I didn't find any directives in 'test.tex', and so didn't do
anything. Is that what you really wanted?
If we run arara with the --log option enabled, we can have a list of directives found in the .tex file.
21 Mar 2013 07:32:10.630 INFO Arara - Welcome to arara!
21 Mar 2013 07:32:10.634 INFO Arara - Processing file 'folheto.tex', please wait.
21 Mar 2013 07:32:10.635 INFO DirectiveExtractor - Reading directives from folheto.tex.
21 Mar 2013 07:32:10.649 TRACE DirectiveExtractor - Directive found in line 1 with pdflatex.
21 Mar 2013 07:32:10.650 TRACE DirectiveExtractor - Directive found in line 2 with clean: { files: [ folheto.aux, folheto.log, folheto.sxc, folheto.synctex.gz ] }.
...
Heiko suggested a --dry-run option to arara, which consists of simulating the execution without actually running the commands. Hopefully it will be available in the upcoming version.
After getting the directives, arara will look for rules.
...
21 Mar 2013 07:32:10.799 INFO TaskDeployer - Deploying tasks into commands.
21 Mar 2013 07:32:10.799 TRACE TaskDeployer - Task 'pdflatex' found in '/usr/local/texlive/2012/texmf-dist/scripts/arara/rules'.
21 Mar 2013 07:32:11.010 TRACE TaskDeployer - Task 'clean' found in '/usr/local/texlive/2012/texmf-dist/scripts/arara/rules'.
21 Mar 2013 07:32:11.083 TRACE TaskDeployer - Task 'clean' found in '/usr/local/texlive/2012/texmf-dist/scripts/arara/rules'.
21 Mar 2013 07:32:11.099 TRACE TaskDeployer - Task 'clean' found in '/usr/local/texlive/2012/texmf-dist/scripts/arara/rules'.
21 Mar 2013 07:32:11.104 TRACE TaskDeployer - Task 'clean' found in '/usr/local/texlive/2012/texmf-dist/scripts/arara/rules'.
...
arara shows the full path for the rule according to the directive. Then the commands will be executed.
...
21 Mar 2013 07:32:11.108 INFO CommandTrigger - Ready to run commands.
21 Mar 2013 07:32:11.108 INFO CommandTrigger - Running 'PDFLaTeX'.
21 Mar 2013 07:32:11.108 TRACE CommandTrigger - Command: pdflatex "folheto.tex"
...
Back to the question. Is it possible to run malicious code through arara? Yes. Is this a problem? No. :) After all, we can get, say, a Perl program and deliberately inject code into its execution. Or write a .tex file with malicious Lua code inside it. Or have a naughty Makefile that runs rm -rf / in our system.
I think the security issues are valid. Let's see an example, the clean rule.
!config
# Clean rule for arara
# author: Paulo Cereda
# requires arara 3.0+
identifier: clean
name: CleaningTool
command: <arara> @{remove}
arguments:
- identifier: remove
default: <arara> @{isFalse(file == getOriginalFile(), isWindows("cmd /c del", "rm -f").concat(' "').concat(file).concat('"'))}
Using this directive
% arara: clean: { files: [ foo.aux, foo.log ] }
will make arara remove two files, foo.aux and foo.log. There's an important check which prevents arara from removing the main .tex file if no files directive argument is provided. Say,
% arara: clean
does nothing.
Let's say we will replace the default instruction by
default: <arara> @{isWindows("cmd /c del", "rm -f").concat(' "').concat(file).concat('"')}
If we try
% arara: clean
the main .tex file (possibly foo.tex) will be gone! Neat isn't it? :)
Of course, we are talking about a faulty rule.
arara has the following workflow:
- Read all directives.
- Find their corresponding rules.
- Expand directives into commands.
- Run all commands.
That's the basic idea behind the program.
It might be worth mentioning that the program makes use of a library to execute these external commands which doesn't allow subshell calls.
Anyway, I really don't know what else to say. :) We are all vulnerable to malicious packages, but that's a risk we need to take. Thankfully, source code has to be available in order to hit CTAN (not entirely true, but true for packages), so we can always check entries for suspicious elements.
As I said, LuaTeX for example allows I/O from Lua, which can also be dangerous. We are exposed to some level of threat at some time, it depends our use. :)
And running arara (or any program) in a server without a sandbox... ouch. :)
Best Answer
Recent minted release have a
finalizecacheoption that saves the cache in a less transient form, then you can change the document to use thefrozencacheoption and from then on--shell-escapeis not needed and it just uses the ready made files in the cache.This means you still need shell-escape to create the highlighting but you can give the document to someone in a form that can be run with no access to the shell at all.