Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
Looking at the Python documentation can be dangerous (twitter.com/marekgibney)
2 points by mg on Dec 2, 2022 | hide | past | favorite | 5 comments


No need for "-m". Just starting Python in an untrusted directory can be a problem.

  % echo "print('Ha-ha.')" > inspect.py
  % python
  ....
  Type "help", "copyright", "credits" or "license" for more information.
  Ha-ha.
  >>>


Yes, I think every use of "python" without a filename is dangerous because it will make python look in the current dir for imports.

The tricky thing is that the python call might be somewhere in a shellscript you use. The issue came up when an irc user reported his computer goes bananas when he cds into a certain dir. Turned out he had his shell set up so that it executes some Python onevery cd. In that dir, there was a "types.py". And the shellscript ran some Python that imported "types".


Huh. Looks like there's a solution in 3.11: https://docs.python.org/3/using/cmdline.html#cmdoption-P

  -P

    Don’t prepend a potentially unsafe path to sys.path:
     * python -m module command line: Don’t prepend the current working directory.

     * python script.py command line: Don’t prepend the script’s directory.
        If it’s a symbolic link, resolve symbolic links.

     * python -c code and python (REPL) command lines: Don’t prepend an empty
        string, which means the current working directory.

    See also the PYTHONSAFEPATH environment variable, and -E and -I (isolated) options.

    New in version 3.11.

Or perhaps '-I'? https://docs.python.org/3/using/cmdline.html#cmdoption-I

    Run Python in isolated mode. This also implies -E, -P and -s options.

    In isolated mode sys.path contains neither the script’s directory nor
    the user’s site-packages directory. All PYTHON* environment variables
    are ignored, too. Further restrictions may be imposed to prevent the
    user from injecting malicious code.

    New in version 3.4.


If you write the python command by hand and are aware of the issue, you can certainly mitigate it.

But if some shellscript you run internally uses some Python via "python -m" or "python -c" running that shellscript is also dangerous. Even if it is completely trustworthy.


What it means is there's a migration path, and we can start using "python -Pm" or whatever in documentation, sh-bang paths, and so on.

Hmmm.... is there a way to tell the entry points which command-line flags to specify for the auto-generated Python start scripts?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: