From: Wes Turner <wes.tur...@gmail.com> Sent: Wednesday, May 23, 2018 4:37 PM To: Alex Walters <tritium-l...@sdamon.com> Cc: Victor Stinner <vstin...@redhat.com>; distutils-sig@python.org Subject: Re: [Distutils] sudo pip install: install pip files into /usr/local on Linux? On Wednesday, May 23, 2018, Alex Walters <tritium-l...@sdamon.com <mailto:tritium-l...@sdamon.com> > wrote: I think the obvious, if socially hard solution, is to make pip panic when it sees its being run as root (without, perhaps, a flag to tell pip "No, I really mean it, run as root"), and default to --user. Maybe default to --user if not in a VIRTUAL_ENV (or a conda env). Yes, of course. The assumption I made is that the behavior being discussed is when pip is not being run in a virtualenv. Pip should default to the most isolated environment available to it (venv, followed by user) It is not a good idea to install packages system wide with pip for reasons more than just clobbering apt/dnf installed packages. I still think the best idea for getting a python program to run system wide is either A: symlink from a inside a venv into something on $PATH, B: just set a shebang to the python in a venv, or C: bundle your application into a .deb or .rpm and use the system package manager to install it. Pip shouldn't be run as root. That being said, installing files as user:group root is less insecure than making them user-writeable; so long as nothing is setuid is root. Until there is something stopping me from uploading an sdist with malicious code in setup.py to pypi, running pip as a root is a bad idea even without user-writeable or setuid. In most cases, it's ill-advised to allow apps to overwrite themselves and/or their dependencies. > -----Original Message----- > From: Victor Stinner <vstin...@redhat.com <mailto:vstin...@redhat.com> > > Sent: Wednesday, May 23, 2018 11:22 AM > To: distutils-sig@python.org <mailto:distutils-sig@python.org> > Subject: [Distutils] sudo pip install: install pip files into /usr/local on Linux? > > Hi, > > pip is currently not well integrated on Linux: it conflicts with the > system package manager like apt or rpm. When pip writes files into > /usr, it can replace files written by the system package manager and > so create different kind of issues. For example, if you check the > system integry, you will likely see that some Python files have been > modified. > > I would like to open a discussion to see how each Linux vendor handles > the issue, and see if a common solution can be designed. > > Debian uses /usr for apt-get install and /usr/local for distutils and > "sudo pip". > > Fedora decided to change pip to install files into /usr/local by > default, instead of /usr, so "sudo pip install" doesn't replace files > installed by dnf (Fedora package manager): > https://fedoraproject.org/wiki/Changes/Making_sudo_pip_safe > > It gives you 3 main places to install Python code: /usr (managed by > dnf), /usr/local (managed by sudo pip), $HOME/.local (managed by pip > --user). > > Would it make sense to make the Fedora/Debian change upstream? At > least, give an opt-in option for Linux vendors to use /usr/local? > > I propose to make the change upstream because there are still issues, > and I don't want to be alone to have to fix them :-) It should be > easier if we agree on a filesystem layout and an implementation, so > we can collaborate on issues! > > > Issues with the current Fedora implementation: > > (1) When Python is embedded in an application, there is an issue with > the current heuristic to decide if /usr/local should be added to > sys.path: > > https://bugzilla.redhat.com/show_bug.cgi?id=1532287 > > (2) On Fedora, "sudo pip install -U" currently removes old code from > /usr and install the new one in /usr/local. We should leave /usr > unchanged, since only dnf should touch /usr. > > https://bugzilla.redhat.com/show_bug.cgi?id=1550368#c24 > > The implementation is made of a single patch on the Python site module: > > https://src.fedoraproject.org/rpms/python3/blob/master/f/00251-change- > user-install-location.patch > > -- > > There are two issues related to the "sudo pip" change, but they > already exist when pip is installed in $HOME/.local: > > (3) Priority issue between PATH and PYTHONPATH directories. > > When the user runs "pip", the pip binary may come from /usr, > /usr/local or $HOME/.local/bin, but the Python pip module ("import > pip") may come from a different path. Which binary and which module > should be used? > > Obvisouly, users can replace these two environment variables... > > (4) Related to (3). Running "pip" may run pip binary of one pip > version, but pick the "pip" Python module of another pip version. > > For example, pip9 binary from /usr/bin/pip, but pip10 module from > /usr/local. > > > Fedora works around issue (4) with a downstream patch on pip: > > https://src.fedoraproject.org/rpms/python-pip/blob/master/f/pip9-allow- > pip10-import.patch > > -- > > I don't well well how Linux distributions handle the issue with "sudo > pip". So don't hesitate to correct me if I'm wrong :-) My goal is > just to start a discussion about a common "upstream" solution. > > Victor > -- > Distutils-SIG mailing list > distutils-sig@python.org <mailto:distutils-sig@python.org> > https://mail.python.org/mm3/mailman3/lists/distutils-sig.python.org/ > Message archived at https://mail.python.org/mm3/archives/list/distutils- > s...@python.org/message/OLGLHTSHLEPLHUTTVNU6L5QFTMNFIB6Z/ > <http://s...@python.org/message/OLGLHTSHLEPLHUTTVNU6L5QFTMNFIB6Z/> -- Distutils-SIG mailing list distutils-sig@python.org <mailto:distutils-sig@python.org> https://mail.python.org/mm3/mailman3/lists/distutils-sig.python.org/ Message archived at https://mail.python.org/mm3/archives/list/distutils-sig@python.org/message/I2F6SW6MVFTJFQNTQCB2HTZC7QOT7GBE/
-- Distutils-SIG mailing list distutils-sig@python.org https://mail.python.org/mm3/mailman3/lists/distutils-sig.python.org/ Message archived at https://mail.python.org/mm3/archives/list/distutils-sig@python.org/message/HMS4UCURNW7C6B6M55HLKOEJCR5BFEQM/
