The Python Software Foundation (PSF) recently announced that it will sponsor work to improve the security of PyPI.
However, these kinds of "typo-squatting" incidents can happen anytime since anyone can upload packages to PyPI and there is no review process to make sure the code doesn't do any harm. These packages were pulled shortly thereafter. The uploaded code collected system and user information and uploaded it to a remote server. For example, in 2017, several packages were uploaded to PyPI with names resembling popular Python libraries. This is a lot more likely than you might think. When a package is installed from the source distribution, this file is executed to perform the installation and execute tasks like inspecting the system, building the package, etc.Įxecuting setup.py with root permissions means we can effectively open up the system to malicious code or bugs. setuptools requires a setup.py file in the root of the project, which describes package metadata and can contain arbitrary Python code to customize the build process.
Most Python libraries and applications today use setuptools as their build system. To explain this, we first have to look at how Python libraries and applications are packaged.
There is another reason why running pip install as root is a bad idea. This can result in an inoperable system, where restoring from a backup or a complete reinstallation is the only way to fix it. Python-py: /usr /lib /site-packages /py /_pycache_ /_error.cpython- 37.pyc exists in filesystemĪnother potential issue is that an operating system can use Python for system tools, and we can easily break these by modifying Python packages outside the system package manager.
Python-py: /usr /lib /site-packages /py /_pycache_ /_builtin.cpython- 37.pyc exists in filesystem Python-py: /usr /lib /site-packages /py /_pycache_ /_metainfo.cpython- 37.pyc exists in filesystem $ sudo pacman -S community /python-pytest This will likely cause issues anytime we try to install, upgrade, or remove any of these dependencies using the package manager.Īs an example, let's try to install pytest again, but now using my system's package manager, pacman: However, one problem is that we just installed a bunch of Python packages into a location the Linux distribution's package manager owns, making its internal database and the installation inconsistent. You can technically get around this by running pip as a root (using the sudo command) or administrative user. This fails because we are running pip install as a non-root user and we don't have write permission to the site-packages directory. '/usr/lib/python3.7/site-packages/site-packages/atomicwrites-x.y.z.dist-info'Ĭonsider using '-user' option or check the permissions. Installing collected packages: atomicwrites, pluggy, py, more-itertools, pytestĬould not install packages due to an EnvironmentError: Permission denied: Python 3.7 looks for packages on an Arch Linux system in the following locations: This all happens globally, by default, installing everything onto the machine in a single, operating system-dependent location. Once all dependencies have been satisfied, it proceeds to install the requested package(s).
When installing packages, pip will first resolve the dependencies, check if they are already installed on the system, and, if not, install them. It can install packages from many sources, but PyPI is the primary package source where it's used. Pip is the de facto package manager in the Python world. Knowing these can help you pick the right tool for the right situation. However, there are some tools and methods that can be considered best practices. The Zen of Python states: "There should be one-and preferably only one-obvious way to do it." This is certainly not always the case when it comes to installing Python packages.