Making sudo pip Safe (Again)
Summary
At the present time, running sudo pip3 in Fedora is not safe. Pip shares its installation directory with dnf, can remove dnf-managed files and generally break the Python 3 interpreter. We propose a series of measures that will make it safe to use.
sudo pip install or sudo pip3 install is still not safe!While this Fedora change took steps to make sudo pip installing less dangerous, there are still corner cases where it might destroy parts of your system. Never ever ever ever use
pip or pip3 with sudo. Use pip --user or Python virtual environments instead.Owner
- Name: Michal Cyprian
- Name: Petr Viktorin
- Name: Tomas Orsava
- Name: Miro Hroncok
- Email: python-maint@redhat.com
- Release notes owner:
Current status
Detailed Description
The danger of using sudo pip3 stems from the fact that both Python dnf packages and sudo pip3 install modules to the same location, namely /usr/lib/pythonX.Y/site-packages.
We aim to move the working directory for sudo pip3 to a more appropriate location: /usr/local/lib/pythonX.Y/site-packages, and modify the Python 3 interpreter in Fedora to scan both above mentioned locations when importing modules. In addition, system-python—a stripped down version of Python 3 for use by system tools—will not read the sudo pip3 install location, making it more secure by being less susceptible to interference by user-downloaded modules.
From the technical standpoint, this will be accomplished by changing the install prefix setting of the distutils install command in the /usr/bin/python3 executable from /usr/ to /usr/local. pip3 and distutils will thereafter use this prefix when determining where to install modules. In addition, the paths /usr/local/lib/pythonX.Y/site-packages and /usr/local/lib64/pythonX.Y/site-packages will be added to the front of the sys.path variable so that modules are imported preferentially from there. These settings, however, will not be modified for the system-python binary, the /usr/bin/python3 executable when running with -I option specified, nor when an RPM build is detected. Therefore, Python RPM packages will continue to be built with the correct installation path for system modules.
The purpose of this change is not to make sudo pip a standard way to install Python packages. Virtual environments and pip3 install --user should still be the prefered options. Nevertheless, sudo pip is far too prevalent an instruction in various guides and installation notes throughout the Internet that there is little hope of changing users' behaviour in this regard.
Important: The changes made during the System Python change were reverted as part of the Platform Python Stack change and will be replaced by a different concept. The specific behaviour of system-python binary described above, will be exactly the same for the platform-python binary. Also, that one was later removed as well. The other (now only) option to make sure system tools won't be affected by any package installed by sudo pip3 command is to use some of the flags provided by Python interpreter (-I, -s) in its shebang.
Benefit to Fedora
Fedora users will benefit from the increased stability of the ecosystem. No longer will they wonder why their Python interpreter or system modules don't work after using sudo pip (see [1], [2], [3], [4]).
In particular, sudo pip3 uninstall contextlib2 should completely undo the effects of sudo pip3 install contextlib2.
The following operations should be completely indistinguishable at the system level from not having done anything at all (except in the sudo logs):
$ sudo pip3 install contextlib2
$ sudo pip3 uninstall contextlib2
Additionally, Fedora will increase it's compliance with the Filesystem Hierarchy Standard,
as user-installed host-specific Python modules will now be correctly located under /usr/local.
Scope
- Proposal owners:
- Modify the distutils install command as described above.
- Modify the site.py script to add additional paths to sys.path when it is needed.
- Other developers: N/A (not a System Wide Change)
- Release engineering: ticket
- List of deliverables: N/A (not a System Wide Change)
- Policies and guidelines: N/A (not a System Wide Change)
- Trademark approval: Not needed for this Change
Upgrade/compatibility impact
Upgraded systems will continue to work as expected. Modules previously installed using sudo pip3 will remain in the location now reseved for system modules, and will need to be manually deleted if removal is required. However, they won't pose a threat to the stability of the system.
How To Test
Test dnf-installed modules
1. Install any Python 3 module using dnf.
2. Check if a corresponding file or directory was created at /usr/lib/pythonX.Y/site-packages/.
3. Run python3 and try to import said module.
4. Run python3 -I and try to import said module.
Test sudo pip3–installed modules
1. Install any Python 3 module using sudo pip3
2. Check if a corresponding file or directory was created at /usr/local/lib/pythonX.Y/site-packages/.
3. Run python3 and try to import said module.
4. Run python3 -I and try to import said module—the import should fail.
User Experience
Running sudo pip3 won't randomly result in a broken Python 3 stack on the user's system.
Dependencies
N/A
Contingency Plan
- Contingency mechanism: Do not push changes to python3 and Python macros into rawhide.
- Contingency deadline: Alpha freeze
- Blocks release? No
Documentation
Discussions
0. python-devel Fedora mailing list (introduction)
1. python-devel Fedora mailing list (implementation)
Release Notes
The location where sudo pip3 installs modules has been changed to /usr/local/lib/pythonX.Y/site-packages, and sudo pip3 is henceforth safe to use. No other changes in user experience are expected.