4 ms·

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 ac

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

ptx 4y ago
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.
- coldtea 4y ago
  >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...
  - ptx 4y ago
    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.

ptx 4y ago

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.

coldtea 4y ago
>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...
- ptx 4y ago
  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.