63

I'm new to Ubuntu, so please bear with me. I installed pip using this command: sudo apt-get -y install python-pip. Then I installed NLTK using the command on their website, which was: sudo pip install -U nltk. But then I stumbled on this question that says that everything I did was a "broken practice". The line that struck me the most was that using sudo pip is inherently wrong and that giving pip too much force could damage operating system files. Can anyone validate this claim?

Note - I only used sudo because when I tried the command apt-get -y install python-pip it gave me 2 errors:

E: Could not open lock file /var/lib/dpkg/lock - open (13: Permission denied)
E: Unable to lock the administration directory (/var/lib/dpkg/), are you root?
2
  • 4
    Instructions telling sudo pip install are inherently wrong. – from stackoverflow.com/a/33004920/95735 Apr 8, 2017 at 21:08
  • 3
    Sorry, sudo pip install is as bad as curl "some-url" | sudo bash installs. Similarly, we've had a few times where some developer used sudo pip install to install some dependency on their workstation, then checked in broken code to the repo because the requirements.txt or setup.py file was missing whatever they installed, and everyone else got to figure out what dependency was needed while the guy was on vacation. Jun 22, 2019 at 4:20

6 Answers 6

87

Both sudo pip install and its other common variant sudo -H pip install should not be encouraged because it is a security risk to use root privileges to use pip to install Python packages from PyPI (Python Package Index).

From https://stackoverflow.com/a/21056000/486919 (emphasis mine):

When you run pip with sudo, you run setup.py with sudo. In other words, you run arbitrary Python code from the Internet as root. If someone puts up a malicious project on PyPI and you install it, you give an attacker root access to your machine. Prior to some recent fixes to pip and PyPI, an attacker could also run a man in the middle attack to inject their code when you download a trustworthy project.

As mentioned at https://security.stackexchange.com/a/79327/8761, it is important to note that anyone can upload Python packages, including malicious ones, to PyPI.

In short, in accordance with the principle of least privilege, don't use sudo with pip to install Python packages from PyPI unless you absolutely need to. Instead, consider using pip install --user (note that pip install with no sudo nor additional flags/options defaults to pip install --user on Ubuntu currently) or virtual environments (such as virtualenv). If you see people recommending sudo pip or sudo -H pip, please tell them not to.

8
  • 5
    If I have used it in the past, how do I clean up what it did?
    – endolith
    Aug 21, 2018 at 10:41
  • 2
    So these instructions are wrong? tensorflow.org/install/install_linux
    – endolith
    Aug 21, 2018 at 10:58
  • 7
    @endolith you may sudo the pip uninstall to undo. Also, though, if the package is from a trusted maintainer, such as tensorflow, numpy, etc, the "aye! security!" argument doesn't really make sense. (Also if you install any malicious package, even as "--user", you're basically screwed anyway. The real rule should be: Don't install code from unknown/untrusted people...except in a container--but even then, not recommended.)
    – michael
    Aug 25, 2018 at 11:25
  • 2
    @endolith Those instructions don't say to use sudo. Maybe they used to and they've seen the error of their ways? :) Feb 27, 2019 at 16:25
  • 3
    sudo pip install can uninstall "old" system-installed Python packages, which can make upgrading or uninstalling those OS packages difficult. sudo pip uninstall doesn't help here, because it removes the new package but doesn't restore the files from the old one. (My colleague R. Zagar goes into more detail in another answer.) Jun 22, 2019 at 4:13
27

You must use sudo to install pip with apt (sudo apt install python-pip), but as stated in edwinksl's answer you should not use sudo to install packages with pip, you should use pip install --user <package> to install only for your user, or use a virtualenv to even further restrict the scope of the package.

Apt installs packages from Ubuntu's repositories, whereas pip installs user-uploaded packages from PyPi which could be malicious.

9

And for a more tempered reply:

  1. You indeed do always have to sudo apt-get install ..., that's just how the tool was designed to work.
  2. Using sudo [-H] with pip install is both possible & optional, depending on what exactly you want to do (and hence, "controversy").

One of Python's mottos is "There should be one-- and preferably only one --obvious way to do it." And like most mottos, it's broken with sardonic glee seemingly at every possible opportunity. (That's why mottos exist, I guess.) Unfortunately, in my most humble opinion, the Python ecosystem consists of many conflicting "hard & fast" rules, never to be broken...except for when "yada yada yada" (devil, details, etc). In almost all cases, this is due to historical evolution of the language & tools (and who wants/needs a history lesson when they just want to get on with their job) -- but also can be due to differences in Mac/Win/*Nix platforms (e.g., Unix/Linux has a similar mentality, but has the advantage of decades more maturity.) So please do take all these "broken practice" & "inherently wrong" cargo-cultists with a huge pinch of salt. Some actually do mean well. (Others are just, well, mean.)

First of all, rather than basic "per-user installs", you'll almost always prefer a virtualenv, because really, that's probably what you'll end up needing. So you might as well start with it now. How this is done, exactly, "depends" (see Python motto, above). If you're using Conda (mostly for Mac & Windows), it'll be set up using Conda. If using "pure" Python [sic], it depends on which version & what python utils you have, but virtualenvwrapper is pretty handy.

Second, just as a counter-example to the "never sudo" rule, you may prefer to sudo -H pip install -U numpy, which is perfectly fine, even advantageous, in that it can allow one to avoid downloading/reinstalling/maintaining big libraries, where you only want/need one version, into every virtualenv separately. Big, popular frameworks like scikit-learn, NumPy, matplotlib, SciPy, pandas, etc., can be installed once & done and re-used across environments. Further, your local friendly sys-admin might be able to get these installed for every user on a system -- and obviously they'd be doing this via sudo, as well, e.g., for more complicated installations, such as TensorFlow.

And, lastly, if you are installing some random 3rd party library that does such-and-such (Twitter API, text munging, code formatting, etc), then I totally agree -- don't install it as root via sudo. Sure, install it as your current user. But just remember, your user account has all your really important stuff.

3
  • 5
    Where "tempered" = "counterproductive hand-wringing faffing inviting confusion for the sake of trying not to hurt anyone's feelings". Just be clear and explicit to avoid confusion: there is never any need to do this as a baseline, including your examples. Unix is indeed "roll your own config and risks", it's literally a C mindset, but like there, don't use malloc where you don't need to. The --user flag does what the OP was asking for and requires no special permissions. You're undermining your good points about virtualenv in the process... nothing "cargo-cultist" about any of this.
    – Benjamin R
    Aug 23, 2018 at 9:07
  • I did already include this perspective in my survey of common responses & opinions (if one reads closely).
    – michael
    Aug 25, 2018 at 8:12
  • Excellent, very wise comment (albeit a bit long, but that was sort of necessary). I am discovering, the hard way, the lack of consistency between what I did in the past on my Debian (Devuan now) system (about 10 years old), with many pip install done as root (no sudo, thanks), also pip3 install done as user or root... What a mess.
    – Pierre
    Mar 4, 2020 at 11:55
4

Using "sudo pip install" can and will overwrite python content provided by your OS vendor. When that happens, any vendor packages affected by this will not pass an "rpm --verify" and your packages will appear to be corrupted.

Do you want to use system-administration tools that your OS vendor has tested, or is it okay to use untested components you downloaded from the internet?

When, not if, a malicious package gets uploaded to PyPI... people who use "sudo pip install" will end up running that malicious payload with full system privileges. Do you want that? (#principleofleastprivilege)

If it's just your laptop, and you're only risking a few cat pictures, then the risk is probably low... but if it's a multi-user system, then the risk is now multiplied by N. If you have data on the system that has value, or system availability or reliability have value, then the risks also go up.

Please feel free to choose your own adventure, but please get the informed consent of the other users that could be affected by your choice. They may not be comfortable with the same level of risk as you.

1

To add to these answers: I do not know about Ubuntu, but on Fedora I am able to use sudo dnf install python3-numpy format to install MANY packages useful to me. This does not have the disadvantage of being insecure (distro repo maintainer has validated packages), but also allows you to install system-wide. Only drawback is that the distro repo versions may be slightly lagging the packages in PyPI.

-5

No, this is correct. I cannot validate this claim. I always use sudo -H with pip. pip can only damage operating system files as much as apt. Only do not use sudo with pip when you want to install only for that user.

2
  • 1
    On your personal computer, when do you need to install pip system-wide? If you're a sysadmin, maybe that's a different story.
    – Benjamin R
    Aug 23, 2018 at 9:09
  • The apt command and your apt packages are designed, secured, signed and deployed as a coordinated suite specific to your OS. Pip packages are designed for a different ecosystem, and very well may break your OS, or even be malicious trojans which can't be trusted since they aren't signed by the OS vendor.
    – nealmcb
    Nov 19, 2020 at 4:06

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .