I have just begun playing around with arara and I am curious if there are safety/security concerns. For example, pdflatex from TeX Live has shell escape disabled by default. If the TeX Live team think that shell escape is too dangerous (and I am not sure that is the reason it has been disabled) to be enabled by default, then I am not sure it is wise to give arara so much power. Is there a way to rein in the power of arara?

One concern I have is that it might be possible to inject a malicious arara directives into a package or the aux file.

I am not so concerned about shell escape, but rather other things that can be done. For example, can an untrusted package use the file contents environment to overwrite the pdflatex rule on the first pass such that on the second pass custom code is run?

  • 10
    arara will enable the shell escape only if the directive requires it: arara: pdflatex: {shell: yes}. Since you are writing the directives, there will be no surprise.
    – egreg
    Commented Mar 20, 2013 at 16:46
  • @egreg but if I compile someone else's document I would need to inspect all the directives. It is also not clear to me if directives can be hidden such that they are not human readable.
    – StrongBad
    Commented Mar 20, 2013 at 18:16
  • I don't think your concerns have anything to do with arara: it will obey only to directives in the main file and not those possibly found in input files. Those in the main file must be in the form % arara: ... so they are easily searchable.
    – egreg
    Commented Mar 20, 2013 at 18:16
  • 7
    @wasteofspace Thanks. If I was a virus author, targeting CTAN and LaTeX is a guarantee that the virus would not spread far. It can only spread to a small ecosystem of users in a well supported community and it will just fizzle and die out. This whole paranoia started with one security employee writing an article as to how TeX/LaTeX could be used to plant a virus. No brainer really. A more plausible scenario is that a disgruntled phd slave would mess-up a couple of declarations in files and annoy a lot of academics in his department.
    – yannisl
    Commented Mar 21, 2013 at 13:56
  • 1
    @YiannisLazarides, the example those researchers gave using the bibtex format was rather interesting. Interestingly enough it let to a tightening of the MikTeX security, AFAIR it now use something like what TL had been doing for years.
    – daleif
    Commented Mar 21, 2013 at 15:24

3 Answers 3


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.

# Clean rule for arara
# author: Paulo Cereda
# requires arara 3.0+
identifier: clean
name: CleaningTool
command: <arara> @{remove}
- 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:

  1. Read all directives.
  2. Find their corresponding rules.
  3. Expand directives into commands.
  4. 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. :)

  • Great description! And very useful tool :)
    – Xavier
    Commented Mar 21, 2013 at 13:55

shell escape will enable pdflatex to save, write, delete and call another program from the system. Some times this can be dangerous as malicious code may be called and executed, endangering the system.

Arara, on the other hand, executes the directives, written by the user, inside the documents. Without a directive, nothing is executed. These directives, written by more of a lovely human (;-), are more human readable. For example if the directive says arara: pdflatex: {shell: yes}, then it is a YES to shell escape and NO otherwise.

In a nutshell,

  1. If you have a directive to use shell escape, only then it will be used.

  2. These directives are found at the top of your source and are easily readable. If you didn't write those directives, you can easily disable the option by putting a no and be safe and happy.

  3. An added advantage of using arara is that you can selectively enable shell escape to a particular document.

Hence, I feel that using arara is safe noting that the author is a good friend of mine ;-).

  • 7
    Ad 2.: The directives can be anywhere in the source file. Commented Mar 20, 2013 at 18:05
  • … but you can easily search for the string “arara”.
    – Speravir
    Commented Mar 20, 2013 at 22:08
  • 2
    I believe this answer to be very optimistic unfortunately. From a quick look at arara's doc, it seems that if someone is able to upload a custom rule to $ARARA_HOME/rules, he can basically run any code through arara... Therefore, I wouldn't dare installing arara on a server. And if I did anyway, I certainly wouldn't dare resorting to arara on said server to process documents automatically, due to the shell escape possibility!
    – Xavier
    Commented Mar 20, 2013 at 22:46
  • 6
    @Xavier: If a random user is allowed to copy a yaml rule into the programs folder of a server, then probably he wouldn't do it. He will directly attack the server and users ;-)
    – user11232
    Commented Mar 20, 2013 at 23:00
  • 1
    On the -shell-escape question, the obvious solution is to have local .yaml files on a server which don't allow this option.
    – Joseph Wright
    Commented Mar 21, 2013 at 11:48

In general, I think of pdflatex as being pretty safe since it can really only read and write files. I understand TeX is Turing complete and you can make it make toast, but I think it would take a lot of work to do something malicious. On the other hand, arara has full access to the command line and I think with relatively little work can be made to do bad things. The type of security hole I was thinking about can be seen with the following example that doesn't fully work

% arara: pdflatex
% arara: pdflatex

identifier: pdflatex
name: pdflatex
command: touch temp.txt
- identifier: target
  flag: <arara> @{parameters.target}

Hello World

The idea is that the filecontents environment is used to overwrite the arara pdflatex rule to do something malicious. To be malicious you would need to replace the benign touch temp.txt and obfuscate the filecontents, but neither of those should be too hard.

The idea behind the attack only works if tex can write to the arara rules directory. I think this is a major limitation, since I believe there are pretty strong constraints on where pdflatex can write. That said, my intended use of arara was for the current directory to be added to the arara rules path.

The reason that the attack doesn't fully work is that the second arara pdflatex directive does not invoke the new pdflatex rule which has been written by the filecontents environment, but rather uses the original rule. The attack is still successful in the the overloaded rule is written and the next time arara is run the malicious rule is used. This behavior is somewhat surprising to me and I am not sure it is intended. Nevertheless, it is useful as a security precaution.

  • I'm nowhere close to imply that Windoze is safe but I can't even update my MikTeX without passing two/three UAC checks so it needs to be fooling user into doing something. And if that is the case then nothing is safe anyway e.g. with the properly hidden keylogger, it can mail the user your IP and pass without doing any fancy OS actions. So getting the horse inside is the mistake, not getting killed afterwards.
    – percusse
    Commented Mar 21, 2013 at 16:28
  • 1
    How often do you compile TeX documents that you haven't written yourself? I guess it could be hidden in a style file and put on CTAN, but it would still write the file when run just with pdflatex so it would be quite easy for people to spot without being in danger from it. And once spotted, the package would get pulled from CTAN. So on a scale from 1 to paranoid, I would rate this as "Theoretical but highly unlikely". Commented Mar 21, 2013 at 16:49
  • This behaviour is intended, as arara builds everything before running any command, so the first batch uses the original pdflatex rule. For the subsequent batches, the new rule will be used. Commented Mar 21, 2013 at 16:49
  • 2
    @AndrewStacey not often, but much more frequently then I run shell scripts from untrusted people without closely inspecting the file.
    – StrongBad
    Commented Mar 21, 2013 at 17:08

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .