The CLI tools shipped in Debian python-rdflib-tools package can load modules from the current directory [1]:

    $ echo 'print("Something")' > cgi.py
    $ rdf2dot
    INFO:rdflib:RDFLib Version: 4.2.2
    Something
    Reading from stdin as None...

This could be a security issue because an attacker could possibly exploit this behavior to execute arbitrary code.

This happens because these CLI tools are implemented as:

    #!/bin/sh
    
    exec /usr/bin/python -m rdflib.tools.rdfpipe $*

"python -m $module", "python -c $code" and "$command | python" prepend the current working directory in the Python path. The Python documentation [2] should probably warn about this. In Python 3, "-I" could be suggested to prevent the script/current directory to be added to the Python path. However, this flag has other effects.

The Python documentation suggests "python -m" commands at some places [3-5]: some form of warning at those places might be nice as well.

See the related behavior of Perl. Perl used to include "." in @INC but this was removed for security reasons [6].


[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=921751.
[2] https://docs.python.org/3/using/cmdline.html
[3] https://docs.python.org/3.1/library/json.html
[4] https://docs.python.org/3/library/http.server.html
[5] https://docs.python.org/3/library/zipapp.html
[6] https://metacpan.org/pod/release/XSAWYERX/perl-5.26.0/pod/perldelta.pod#Removal-of-the-current-directory-%28%22.%22%29-from-@INC

The change in behavior of Perl was discussed in https://mail.python.org/pipermail/python-ideas/2017-June/045842.html

Documentation is one thing. But I'm interested to discuss again (in 2019) the idea of changing the default behavior in Python 3.8 to enhance the "default" security.

I don't know a good reason for including $PWD in sys.path for "python -m", I expect only scripts that run other scripts (such as coverage.py) might want the current behaviour and those can adjust to new behaviour.

For "python -c CMD" the current behaviour is easier to defend, this matches the behaviour w.r.t. sys.path of typing the command in an interactive session.


The behaviour for scripts (add the directory where the script is located to sys.path) is also easier to defend: that makes it easier to use scripts without installing stuf and without explicitly managing sys.path. 

I've used this in the past to split scripts into modules without installing modules in a global directory, but these days I tend to use virtual environment for that. I guess the usefulness of this behaviour depends on the type of user: the current behaviour is useful for more casual use of Python (which includes people learning python)

+Nick (who may have some insight here)

If someone wants to change the Python default behavior, a PEP will be required since it would be a major backward incompatible changes. A lot of details and use cases must be discussed and documented.

related: issue #13475

Note that I've asked Guido to comment about CWD in sys.path on issue #35969.

Folks use "python -m myproject.mymodule" to run code that they're working on all the time - it's currently the only way to get sys.path right for cases like that (otherwise you're exposed to the double import trap, where you can get two copies of a submodule under different names).

We even use it to run CPython's own test suite as "./python -m test".

That said, over in https://bugs.python.org/issue33053#msg314192 I came up with a plausible migration path away from doing that implicitly - we'd just have to introduce a spelling for doing it explicitly instead, and relative imports give us a precedent for that.