6 ms·

Looking at the Python documentation can be dangerous

2 points by mg 4y ago

eesmith 4y ago
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. >>>
- mg 4y ago
  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".
  - eesmith 4y ago
    Huh. Looks like there's a solution in 3.11: https://docs.python.org/3/using/cmdline.html#cmdoption-P 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 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.
    - mg 4y ago
      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.
      - eesmith 4y ago
        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?

2 points by mg 4y ago

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. >>>

mg 4y ago
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".
- eesmith 4y ago
  Huh. Looks like there's a solution in 3.11: https://docs.python.org/3/using/cmdline.html#cmdoption-P 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 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.
  - mg 4y ago
    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.
    - eesmith 4y ago
      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?