I am working on a tool (Python, may or may not be important) that will allow a user to maintain a configuration file containing arbitrary shell and/or language code to be executed on particular events and intervals. The code will potentially involve multiple statements.
I understand there are potential behavioral and security risks associated with executing arbitrary code from a file, but I don’t think this is a concern because the configuration file is managed only by the end user. However, let me know if I’m overlooking something major.
My main question: what is the best way to store this code in a configurable way?
Some concepts I’m considering to store the code…
In a shared config file (which many Python libraries already look for):
# setup.cfg
[my_program]
command_1 = cd /tmp && touch foobar
In a YAML file:
# my_program.yaml
command_1: cd /tmp && touch foobar
In a source file as arguments to subprocess.call():
# settings.py
command_1 = [['cd', '/tmp'], ['touch', 'foobar']] # requires special handling of 'cd'
In a source file as a function:
# settings.py
import os
import subprocess
def command_1():
os.chdir('/tmp')
subprocess.call(['touch', 'foobar'])
5
How about storing the commands in an actual executable file? The end user creates a bash/python/ruby script, and all they supply to your configuration is the name of the script to execute.
This allows the script to be arbitrarily simple or complex, and also lets the end user use any scripting language supported by their own environment.
Finally, they will need permissions to make the script file executable for this to work, which means they already had permissions to create and run any script anyways.
3
Well, for your example script only the first two methods will actually work. It has a cd in it, and therefore the two commands must be part of the same shell script.
Therefore, if you want to use commands that have the form of a shell script, you have to store them in form of a string anyway. If the code you want to store may become longer, YAML might be the better idea, since it can handle multi-line strings better.
0
One option I’m considering is to have users create a Makefile with specific target names.
Advantages:
- all commands are locally testable
Disadvantages:
- requires
make