New feature idea: sudo protection

[msabramo]

This is inspired by pypa/pip#2403

• I keep wanting to come up with some mechanism to prevent folks from screwing themselves by activating a virtualenv and then doing sudo pip install and thinking that it's installing to their activated virtualenv when in fact, it's installing to the global site-packages because sudo is usually configured to throw out most environment variables and VIRTUAL_ENV is probably one of them.
• I have submitted a PR or two to pip to try to prevent this situation by emitting warnings when pip is invoked with sudo, but folks make the point that it's valid to want to use pip with sudo.

So I decided to rethink this with the observation:

Maybe we shouldn't prevent pip from being used with sudo, but maybe the real problem is that people are using sudo after activating a virtualenv.

My idea is to have the activate script create a sudo that overrides the real sudo and prints a warning.

Here's a prototype of the idea without actually coding it up, because there's a good chance that this idea is too crazy and will be rejected, similarly to how the pip idea was rejected.

[marca@marca-mac2 /tmp]$ virtualenv testenv
New python executable in testenv/bin/python
Please make sure you remove any previous custom paths from your /Users/marca/.pydistutils.cfg file.
Installing setuptools, pip...done.
[marca@marca-mac2 /tmp]$ source testenv/bin/activate
[marca@marca-mac2 /tmp]$ sudo() { echo "Warning: If you use sudo after activating a virtualenv,\nPython-related commands may not operate within the virtualenv,\nbecause sudo tends to drop environment variables like VIRTUAL_ENV."; echo "You can avoid this warning in the future by replacing 'sudo' with 'command sudo'"; echo "\nSleeping for 5 seconds to give you a chance to abort...\n"; sleep 5; command sudo "$@" }
[marca@marca-mac2 /tmp]$ sudo pip install something_that_would_bork_my_system_python
Warning: If you use sudo after activating a virtualenv,
Python-related commands may not operate within the virtualenv,
because sudo tends to drop environment variables like VIRTUAL_ENV.
You can avoid this warning in the future by replacing 'sudo' with 'command sudo'

Sleeping for 5 seconds to give you a chance to abort...

Downloading/unpacking something-that-would-bork-my-system-python
  Could not find any downloads that satisfy the requirement something-that-would-bork-my-system-python
Cleaning up...
No distributions at all found for something-that-would-bork-my-system-python
Storing debug log for failure in /Users/marca/.pip/pip.log

Good idea worth a PR?

or too annoying?

Cc: @sudarkoff, @aconrad

[aconrad]

Interesting. I do prefer this approach over the pip one. A few thoughts:

• The prototype above could be annoying for non pip-related commands. It should probably check if the command being sudo'ed is pip or an alternative install tool (easy_install, ...).
• The sleep would be annoying if I was sure that sudo pip is really what I want to do since it's a valid use case. I would prefer having a prompt such as Install Python package outside your virtualenv with sudo? [y/n] so I don't have to wait for the sleep to complete.
• This sleep/prompt should only be shown if the caller is a TTY to prevent scripts from pausing/blocking.

I think this could be useful and may save a few systems. I just don't know what the implications are when it comes to overriding the real sudo command.

[tysonclugg]

My preference is that no protection is provided, someone can create a nosudo package that creates the dummy sudo script if they feel it's a worthy cause.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Just add a comment if you want to keep it open. Thank you for your contributions.