What's the problem this feature will solve?
Building a wheel results in execution of a lot of potentially vulnerable or untrustworthy code:
setup.py
- build system
- setuptools plugins, which can have large dependencies trees
- variables imported from modules using
attr: in setup.cfg and tool.setuptools.dynamic section (it is planned to be fixed somewhen in sallow only statically parsed stuff by default).
- console tools called by
setuptools plugins.
There is usually no reason to call all these from a privileged user. But some packages are still available on pypi as sdists only, so users installing them with sudo pip result in them being fetched and built from root. I personally have disabled fetching anything from pypi, BTW.
The most severe issue for me is editable install. It is extremily inconvenient to rebuild wheels and reinstall them after every minorest change when developing python code that must be run from root. I know it introduces local privilege escalation, but TBH if one runs untrustworthy code on own machine, he is already deeply in danger.
The issue got more severe today because of pypa/setuptools-scm#707 . setuptools_scm is a tool to get version from git tags, it calls git for that. But pip runs wheel building from root, while the source dir is usually owned by the user initiating the build. The recent fix in git to eliminate such vulnerabilities checks that the user running git is the same as the user owning the repo. Of course fakeroot is the workaround, but I think a more correct solution is needed.
Describe the solution you'd like
- pip should detect the user that has started it via
sudo
- pip should build a wheel from that user and only install from
root
- pip should detect if there are any sandboxing solutions present in the system, and should use it to allow wheel building process to write only to the source dir and to the build dir.
Alternative Solutions
No.
Additional context
Code of Conduct