Agreed. I was faced with a couple inherited binaries which wouldn't work in subprocess without the shell, but I still needed to prevent injection. Your lsopts example is a good one.
Take care,

Ron

But your tip still seems helpfull, if you want to mix expanded and unexpanded parameters:
Like in
lsopts="-l"; subprocess.call(["ls $0 *.py",lsopts], shell = True)
the parameter lsopts is protected against injection, while "*.py" will correctly expand to all py-files in the working directory.

Thank you.

I found subprocess to be weird, then I figured out that the "shell = True" keyword argument really messes everything up. However, my target commands didn't function properly without it.

Security becomes a big concern when setting shell = True. Taking a closer look at the subprocess security promise: "this implementation will never call /bin/sh implicitly" (http://docs.python.org/library/subprocess.html#security). As you point out in the subprocess source, the executable is now /bin/sh. We are now explicitly calling /bin/sh … !

Your suggestion is useful for subprocess calls; "If you really want to use shell expansion, it is probably best to put the whole command in one string." This helps avoid inserting numerous positional parameters. However, this provides an opportunity for injection.

subprocess.call(r'echo arg0 arg1 arg2 arg3; echo 123; echo $HOME', shell = True)

output:
arg0 arg1 arg2 arg3
123
/home/username

A workaround is: keep things in a list (not a string) and use positional parameters. For example:

subprocess.call([r'echo $0', r'arg0 arg1 arg2 arg3; echo 123; echo $HOME'], shell = True)

Here, the output is:
arg0 arg1 arg2 arg3; echo 123; echo $HOME

That looks to be sanitized. The $0 trick with a 2 element list allows you to use subprocess with the shell (some calls will need it) while ignoring the exact number of arguments (to avoid extra work/mistakes in listing a series of positional parameters).

This is now a ridiculously long comment, but I hope it helps to avoid shell injection!
Thanks!

-Ron

In short: I don't agree.
It's a bit like saying "to protect yourself from remote exploits, turn off your computer". It's true, but it does not really help. You call other programs, because they solve a problem for you. To turn these into longrunning 'deamons' may take quite some effort.
The spawning of a subprocess for a certain task is quite common in unix, including noteble examples like qmail by Daniel J. Bernstein. In qmail it is an explicit security feature.

While I know very little about launchd reading the "Some background—why launchd?" and "Benefits of launchctl" sections it seems to me that you misunderstood the purpose of it. Though there might reasons to run subprocess through it, e.g. if you want to replace one program by another, or you want to fine-control the amount of memory that a certain subprocess may consume without stopping your main application. If this is worth the overhead (startup, configuration, programming, …) depends on the speciffic situation.

I still plan to write more about it. Some day.