Hacker News Reader

Comment by ptx | Hacker News Reader

Loading code from the current working directory is not a good idea. It would make it unsafe to run a Python program from any directory that's not completely trusted, e.g. if we imagine "ls" having this feature:

  [root@localhost]# cd /home/someguy
  [root@localhost]# ls

Oops, now someguy can execute arbitrary code as root.

Windows used to do this with DLL files and has since had to add various modes where it's either disabled or (in the default "safe DLL search mode") deprioritized in the search order: https://learn.microsoft.com/en-us/windows/win32/dlls/dynamic...

View on HN

That's not the proposal, the idea with PEP 582 is python's executable will check a local directory for a venv and activate it if necessary, but only when you actually run python (not automatically in your shell).

I was responding to the parent comment which suggested that Python "should look for a .venv directory in the current working directory".

Doing this "only when you actually run python" doesn't help. It would make it unsafe to run for example (looking at my /usr/bin) "ufw", "hg", "smbinfo", "samba-tool" or "routel" without first making sure that the current working directory (i.e. the one that you have currently set with "cd" in your shell) is not writable by any other user and doesn't contain anything unexpected.

>Doing this "only when you actually run python" doesn't help

Node.js does it this way, and it works just fine. Not sure what you think the problem is.

>Doing this "only when you actually run python" doesn't help. It would make it unsafe to run for example (looking at my /usr/bin) "ufw", "hg", "smbinfo", "samba-tool" or "routel" without first making sure that the current working directory (i.e. the one that you have currently set with "cd" in your shell) is not writable by any other user and doesn't contain anything unexpected

Why would the current working directory matter as to that?

First, if somebody has write access to your local directory you have worse issues.

They could for example overwrite the py/pyc dependencies or replace the python inside the virtual env, and their code will be executed if you run any of the items in the bin or even import those python deps.

Whether Python "looks for a .venv directory in the current working directory" or not doesn't mattter. It will just mean that you need to activate the .venv first to get those in your PATH. But that's why you had the .venv there in the first place, to activate and use it.

Whether you activate it manually or not doesn't matter...

To be clear, by "current working directory", I mean the directory returned by os.getcwd(), not the directory where the script is located. This is what I think the problem is:

1. One might want to run utility programs from arbitrary working directories, for example running "ls" in another user's directory (the example I gave in my first post), with "ls" being the utility program in this example.

2. One might want to implement such utility programs in Python, which is the case with e.g. "ufw", "hg" and "smbinfo" (the examples I gave in my second post).

3. If the suggestion to load Python modules from the current working directory is implemented, and a utility program is implemented in Python as in (2) and one runs it with a current working directory controlled by another party as in (1), then that party is able to execute arbitrary code as the user running the utility program, resulting in privilege escalation.

To make this more concrete, let's say we reimplement "ls" in Python as "ls.py" and install it in /usr/bin. If we then (quite reasonably, I think?) use our "ls.py" as root to list the files in /tmp, which is writable by other users...

  # cd /tmp/
  # /usr/bin/ls.py

then, if Python loads code from ".venv" in the current working directory, whoever created "/tmp/.venv" is able to execute code as root.

It already is though. Python loads modules from the current directory. As soon as you import a non default module, its already over.

Does it? As far as I know, it loads modules from the script's directory (which is usually fine), not from the current working directory.

  $ mkdir bin_dir
  $ echo 'print("mymod loaded as expected.")' >bin_dir/mymod.py
  $ echo 'import mymod' >bin_dir/script.py

  $ mkdir working_dir
  $ echo 'print("Oops, game over!")' >working_dir/mymod.py

  $ cd working_dir/
  $ python3 ../bin_dir/script.py
  mymod loaded as expected.

Reply on news.ycombinator.com