-
Notifications
You must be signed in to change notification settings - Fork 3k
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
Add a warning when run as root (e.g., sudo pip) #9394
Conversation
that's some good stuff, thanks @hroncok. i added the venv check and updated the warning message with the tip |
/cc @dstufft since last I checked he was opposed to just doing this. |
There's still one sticking point with this: docker containers give you root by default. I don't think we should be calling out the use of pip in root shells like that. |
I think we should. Even in docker, installing with pip as root can lead to serious problems. |
Perhaps. But that's still more disruptive than I'd like. I haven't seen a Dockerfile that's using pip that even tries to install as non-root. Is it even possible to use it as non-root from a Dockerfile? |
It is possible, however not that straightforward. I get your point. |
Is this really that disruptive? It’s “just” a warning, people ignore warnings all the time when they feel like it. Using root in a Docker container is ultimately still not best practice, and it’s arguably still not a bad idea to show the warning in this situation. If it’s really that important, we can have |
|
Yeah, most people don't use Docker, so I think the benefit of preventing mis-installations exceeds whatever disruption a one-line message causes to Docker users. Plus this is just a |
I can confirm that using virtual environments inside docker is definitely a thing |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Alrighty. Consider me convinced that this is a good idea overall.
This is the first time I'm looking at the code in this PR and... I have some opinions about how we should implement this. :)
Changes requested by @pradyunsg have been implemented. |
src/pip/_internal/cli/req_command.py
Outdated
"It is possible to break packages installed for your " | ||
"operating system or by different package managers. " | ||
"You should use a virtual environment rather than trying " | ||
"to run as root. This may help resolve permission issues.") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would try making the message shorter. The longer the warning is, the less likely users would read it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is shorter, yet OTOH the user has no idea what to do instead:
logger.warning("Running pip as root may destroy your system.")`
Do you think providing a link would work? I.e.:
logger.warning("Running pip as root may destroy your system. See https://bit.ly/pip-root for details.")`
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A link to the documentation feels like a good compromise to me.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There's two situations I can think of where someone would run pip with sudo:
- Unintentionally: it's often easy to forget which commands need sudo and which don't. In this case, the "Running pip as root may break packages" part of the message should be enough to dissuade them; I don't think we'll need to link an essay.
- Intentionally: A user may run pip without sudo, encounter a permission error, and retry with sudo. We should discourage this by suggesting virtual environments. This is where a link could help imo.
How's this?
Running pip as root may break packages and permissions. Permission errors should be fixed with venv: https://docs.python.org/3/library/venv.html
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Either of the followings would be a better link IMO:
- https://packaging.python.org/tutorials/installing-packages/#creating-virtual-environments
- https://docs.python.org/3/tutorial/venv.html
The library documentation page covers more on the programmatic interface and isn’t very useful for the audience we target here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like @hroncok's link-based suggestion. I'd say use https://pip.pypa.io/warnings/root-usage
for that right now. We can setup a redirect in our RTD configuration, to make it point to the right place once this is merged.
It'll also defer the discussion on what the right place is, which I like. 🙃
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I still think we should explicitly call out permission errors and venv in the warning message, since that's by far the most common misuse of sudo.
So instead of a generic https://pip.pypa.io/warnings/root-usage
redirect, how about we specify https://pip.pypa.io/warnings/venv
and tentatively redirect it to https://docs.python.org/3/tutorial/venv.html
?
Updated warning message:
Running pip as root may break packages and permissions. Permission errors should be fixed with venv: https://pip.pypa.io/warnings/venv
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How about "Permission errors should be fixed with venv" -> "If you need to install packages not supplied by your system package manager, use a virtual environment: https://pip.pypa.io/warnings/venv"? Focus on what the user wants to do, rather than simply on fixing the error they got.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should call this out for what they're doing here, and provide better guidance on what they should be doing in the link (using a virtualenv, why, what the risks are etc).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shorter message with a focus on the user:
logger.warning("Running pip as root may break packages and permissions. "
"You should install packages reliably by using venv: "
"https://pip.pypa.io/warnings/venv")
I agree that technical details belong in the link.
I just stumbled upon on this part of the pip code base which warns about permissions and reckons that the user might be using sudo. I thought this might be relevant to the conversation here. |
Good call out, this warning often appears when users run as root too. But I think it's useful to keep both cache and root warnings separate, since each case can still exist independently:
|
@uranusjr @pradyunsg @pfmoore Rebase is complete. We still need to set up a redirect from https://pip.pypa.io/warnings/venv to https://docs.python.org/3/tutorial/venv.html before merging, but that should be the last step! |
#9680 configures the redirect. would appreciate a review :) |
Configured the redirect. |
Thanks @pradyunsg, this should be good to merge then. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you do a rebase of this PR? I'd like to make sure it still passes the current linter setup.
@pradyunsg Sure, rebased without issues. |
Thanks for this PR! ^.^ |
I'm adding the current version of the warning message so this PR with some explanations can be found more easily:
|
Both the documentation of the official python docker images and the official docker docs install pip packages with sudo. I can't find any information on the web as to how it should be done instead. Would you please explain how I'm supposed to get rid of the warning when using a |
Processes In Containers Should Not Run As Root Deploying Python Applications with Docker - A Suggestion (It covers a ton of stuff, but your can search for virtualenv to find the relevant parts.) Maybe we should write a documentation page on this, and point |
@hroncok What issues were you thinking of here? Generally, I recommend people use Docker (well any container) or virtualenv, not both. |
For example, if your docker container image is based on a distribution that uses Python for some critical software (let's say the distribution's package manager is written in Python), using pip with root can essentially turn that package manager unusable and depending on the container image usage, this might break use cases of people building stuff on top of it. |
It is totally legitimate case to use pip with root user. I can give you a very good example In our Production Dockerflie Image for Apache Airflow we have two segments: Segment 1) installs all the packages for Apache Airlfow including all the packages that need "build-essentials" - i.e. compilation support. This is all done as "root" user and installed with Then we have segment 2) which uses "root" user to install all "debian" packages, but then we switch to "airflow" user - and first thing we do - we copy the ".local" folder of the "root" user from segment 1 to segment 2 - changing the ownership of all files to "airflow" while copying (nice feature of
This results in 25-30% smaller images - ca. 250 MB (no need to keep build-essentials and -dev packages around). Also any kind of secrets you might need in segment 1 (for example .pypirc containing passwords to your registry) are not present in the final "segment 2" even if they needed to be copied to "segment 1" in order to be able to install "private packages". I wonder if the best solution here is:
I would really love to be able to have "warning-free" docker build of Airflow Image. It's not possible currently (or maybe you need stronger magic). |
So, technically, the Fedora patch did allow you to use |
This change discourages the usage of pip as root by showing a warning when pip install is run with sudo.
Fixes #6409
...and potentially helps helps prevent hundreds of future issues related to
sudo pip
: https://github.com/pypa/pip/issues?q=is%3Aissue+%22sudo+pip%22