bug#41619: [PATCH] Mark python-shell-virtualenv-root as safe local variable

[Philip K.]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Glenn Morris <rgm@gnu.org>
>> Date: Sat, 13 Jun 2020 13:20:29 -0400
>> Cc: eliz@gnu.org, philip.kaludercic@fau.de
>> 
>> 
>> I don't understand how python-shell-virtualenv-root can be considered a
>> safe local variable. Surely it controls what "python" executable gets run.
>> 
>> As a test, I did:
>> 
>> python3 -m venv /tmp/foo
>> 
>> I then replaced /tmp/foo/bin/python with a shell-script:
>> 
>>  #!/bin/bash
>>  echo oh-oh
>> 
>> I then ran:
>> emacs -Q --eval '(setq python-shell-virtualenv-root "/tmp/foo")' -f 
>> python-mode
>> C-c C-p
>> 
>> This gives an inferior Python buffer with contents:
>> 
>>   oh-oh
>> 
>>   Process Python finished
>> 
>> In other words, this looks like a recipe for arbitrary code execution.
>
> Philip, could you please look into this?  TIA.

First of all, sorry for the delayed response. I look a look at how
python.el uses python-shell-virtualenv-root and how virtualenv works in
general, and I think that Glenn's analysis is corret. One would have to
make sure that /tmp/foo/bin/python is an actual Python installation. Now
on my system it seems like python/python3 is always a symbolic link to
/usr/bin/python3 (if the virtual enviornment was created using python3),
but checking is neither portable or totally solves the issue.
with all odds agains you, you cannot 

I've also noticed that in other places, people automatically activate
python environments, if for example in a shell, the path
`./venv/bin/activate` is valid, but nowhere could I find any validation
to ensure that arbitrary code isn't executed :(

Ultimatly, my estimation was wrong, and the variable shouldn't be marked
as safe, at least not with any heuristics that could warn the user if
the path is suspicious.

-- 
        Philip K.