On 05.02.2013 09:02, Lennart Regebro wrote: > On Tue, Feb 5, 2013 at 8:42 AM, M.-A. Lemburg <[email protected]> wrote: >> On 05.02.2013 02:36, Nick Coghlan wrote: >>> Something that caught my attention in the recent security discussions >>> is the observation that one of the most common insecure practices in >>> the Python community is to run "sudo pip" with unsigned packages >>> (sometimes on untrusted networks). >>> >>> To my mind, this is a natural reaction to the user experience of pip: >>> you run "pip install package", it complains it can't write to the >>> system site packages directory, so you run "sudo pip install package" >>> to give it the permissions it clearly wants. >>> >>> If pip used the user site packages by default (when running as anyone >>> other than root), that dangerous UI flow wouldn't happen. Even when >>> pip was run outside a virtualenv, it would "just work" from the users >>> perspective. It also has the advantage of keeping systems cleaner by >>> default, since there will be a clear separation between system >>> packages and pip-installed packages. >>> >>> Thoughts? >> >> -1. You'd be hiding a real problem by not telling the user that >> there's a permission problem to think about. > > One problem is that the user is trying to install some random package > to the system python. This is only likely to happen on a personal > machine (I do hope sysadmins have more sense than that) and installing > it to user site packages will then still make it available for all > python software that uses the system python that runs under that user. > And that's probably quite a lot. Hence security issues remain, in that > this package can get picked up by other python software running, and > on Linux systems, that's quite a lot. :-) > > But, it's still a lot better than running it as sudo, in which case > the setup.py file could simply decide to install a rootkit. > > That said, I think it would be better to explain to the user what > happens. I could imagine that if you try to install where you don't > have the right, it asks if you meant to install it to the user site > packages or to a virtualenv, for example?
That would be a much better idea, IMO. The solution Nick proposed also has another issue: it would install packages meant for a virtualenv in the user's site packages dir (outside the virtualenv)... "If pip used the user site packages by default (when running as anyone other than root),..." Looks like a slippery road if you try to make pip guess what the right installation dir should be, e.g. by trying to detect that it's running in a virtualenv, the Python3 venv, pyrun or a user's local Python installation. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Feb 05 2013) >>> Python Projects, Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope/Plone.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::::: Try our mxODBC.Connect Python Database Interface for free ! :::::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ _______________________________________________ Catalog-SIG mailing list [email protected] http://mail.python.org/mailman/listinfo/catalog-sig
