It has security issues just when you run the function with arguments taken from users. For example:

import os
def do_clear(command): # Notice command is sent as argument from outside world and hence this makes it vulnerable
    os.system(command)

If the method is called with for example

do_clear('rm -f */*')

Then it is possible that it deletes all the files of current directory. But if the 'clear' command is to be directly used, you do not have to worry about the security issue, as only 'clear' is run in all conditions. So the following function is secure enough.

def do_clear(): # Notice command is not sent as argument from outside world
    os.system('cls' if os.name == 'nt' else 'clear') # This is not risky as os.system takes clear/cls command always.

Anything that uses the shell to execute commands is insecure for obvious reasons (you don't want someone running rm -rf / in your shell :). Both os.system and os.popen use the shell.

For security, use the subprocess module with shell = False

Either way, both of those functions have been deprecated since Python 2.6

The objection is entirely legitimate.

Let's say that your command looks like:

def post_result(result_string):
  os.system('curl http://example.com/report-result/%s' % (result_string,))

Now, what happens if you're told to report a result that contains ; rm -rf ~? The shell invoked by os.system() runs curl http://example.com/report-result/, and then it runs a second command of rm -rf ~.

Several naive attempts at fixes don't work.

Consider, for example:

# Adding double quotes should work, right?
# WRONG: ''; rm -rf ~'' doesn't work here, but $(rm -rf ~) still does.
os.system('curl http://example.com/report-result/"%s"' % (result_string,))

# ...so, how about single quotes?
# STILL WRONG: $(rm -rf ~) doesn't work on its own, but result_string="'$(rm -rf ~)'" does.
os.system("curl http://example.com/report-result/'%s'" % (result_string,))

Even if you avoid direct shell injection vulnerabilities, using a shell exposes you to other kinds of bugs.

At startup time, a shell does a number of operations based on filesystem contents and environment variables. If an untrusted user can manipulate your program into setting environment variables of their choice before calling os.system(), they can cause a file named in ENV to have its commands executed; can shadow commands with exported functions, or can cause other mischief. See ShellShock for a well-publicized historical example.

And that's before considering other things that can happen to your data. If you're passing a filename to a shell, but unknown to you it contains whitespace and glob characters, that filename can be split into / replaced with other names.

The official Python documentation warns against shell use.

Quoting a warning from the Python subprocess module documentation, which is also relevant here:

Warning: Executing shell commands that incorporate unsanitized input from an untrusted source makes a program vulnerable to shell injection, a serious security flaw which can result in arbitrary command execution. For this reason, the use of shell=True is strongly discouraged in cases where the command string is constructed from external input:

>>> from subprocess import call
>>> filename = input("What file would you like to display?\n")
What file would you like to display?
non_existent; rm -rf / #
>>> call("cat " + filename, shell=True) # Uh-oh. This will end badly...

shell=False disables all shell based features, but does not suffer from this vulnerability; see the Note in the Popen constructor documentation for helpful hints in getting shell=False to work.

When using shell=True, pipes.quote() can be used to properly escape whitespace and shell metacharacters in strings that are going to be used to construct shell commands.

os.system() has all the same faults as subprocess.Popen(..., shell=True) -- even more faults, since subprocess.Popen() provides a way to pass data out-of-band from code, and so can be used safely.

Native Python libraries don't call shells for work that the Python runtime can do.

Python has a socket library in its standard library interface, which directly invokes operating system and libc calls to create network connections and interact with them. There is no shell involved in these syscalls; arguments are C structs, C strings, etc; so they aren't prone to shell injection vulnerabilities in the same way that os.system() is.

Some Python libraries, like libcurl, may be slightly less native insofar as they use their own C libraries rather than only calling out to the operating system through functions included in the Python runtime itself; even then, though, these OS-level syscalls are at a much lower level than any shell.

While the access-using code is unsafe, the second code snippet doesn't solve the security issues. These docs should be changed.

The purpose of os.access is to test whether the real user id has permission to access a file when the real and effective user ids are different. The danger with the os.access snippet is that the user could place a file access returns True for in the location being tested, then swap it out for a file access would have returned False for, bypassing the check. Since open uses the effective user id, the open call can still work, bypassing the access check.

The second snippet doesn't solve this problem. Now the user doesn't even need to go through the switcheroo. No part of the second snippet checks the real user id.