Avoid starting a process with shell intervention

[DimitriPapadopoulos]

This is flagged as a security issue by code analysis tools such as DeepSource.io:

Spawning of a subprocess using a command shell is dangerous as it is vulnerable to various shell injection attacks. Great care should be taken to sanitize all input in order to mitigate this risk. Calls of this type are identified by the use of certain commands which are known to use shells. [...] It is recommended to use functions that don't spawn a shell. If you must use them, use shlex.quote to sanitize the input by changing it to the shell-escaped version.

See: https://docs.python.org/2/library/subprocess.html#replacing-os-popen-os-popen2-os-popen3

We do not necessarily have a security issue in this specific case, but why start a shell any way?

Note: os.popen2 has been deprecated since Python 2.6 and is obsolete, but let's handle that elsewhere: https://docs.python.org/2/library/os.html#os.popen2

Deprecated since version 2.6: This function is obsolete. Use the subprocess module. Check especially the Replacing Older Functions with the subprocess Module section.

[FrancescAlted]

I am not sure I understand this. How the shell intervention is avoided here exactly?

[DimitriPapadopoulos]

See: https://docs.python.org/2/library/subprocess.html#replacing-os-popen-os-popen2-os-popen3

On Unix, os.popen2, os.popen3 and os.popen4 also accept a sequence as the command to execute, in which case arguments will be passed directly to the program without shell intervention.

If you pass "ls -l", you will actually exec sh ls -l. The exec call in the C library, and other similar functions, expect distinct arguments for the path of the executable and the arguments: https://pubs.opengroup.org/onlinepubs/9699919799/functions/exec.html

[FrancescAlted]

Ah, got it. Thanks!