Skip to content

New feature idea: sudo protection #727

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
msabramo opened this issue Mar 6, 2015 · 3 comments
Closed

New feature idea: sudo protection #727

msabramo opened this issue Mar 6, 2015 · 3 comments

Comments

@msabramo
Copy link

msabramo commented Mar 6, 2015

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
Copy link

aconrad commented Mar 6, 2015

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
Copy link

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
Copy link

stale bot commented Jan 14, 2019

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.

@stale stale bot added the wontfix label Jan 14, 2019
@stale stale bot closed this as completed Jan 22, 2019
@pypa pypa locked and limited conversation to collaborators Jan 14, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants