Summary: | dev-python/cryptography-0.9.3 fails during install - ACCESS DENIED: mkdir: /home/paul/lib/python/__pycache__ | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Paul McDermott <pmcdermott98> |
Component: | Current packages | Assignee: | Python Gentoo Team <python> |
Status: | RESOLVED OBSOLETE | ||
Severity: | normal | ||
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | 561694 | ||
Bug Blocks: | |||
Attachments: |
Portage log file
emerge --info |
Description
Paul McDermott
2015-09-05 09:38:11 UTC
Created attachment 411044 [details]
Portage log file
Created attachment 411046 [details]
emerge --info
which version of dev-python/enum34 with which USE do you have installed? 1.0 I have just noticed that I have an 'enum.py' at /home/paul/lib/python, and the above directory is in my PYTHONPATH. But I'm thinking an install of this ebuild (and Gentoo python installs in general) should *not* be picking up personal libraries--there could be also sorts of crazy stuff on the path... Why is a user's dir in your global PYTHONPATH? I would have said that it is the other way round: why shouldn't a user's library be included on the PYTHONPATH? What seems to be happening is that the PYTHONPATH set in my user account .bashrc file is being carried across to the root user environment when I 'su'. But all this would seem to me to be normal practice. Shouldn't Gentoo be ignoring any custom paths in PYTHONPATH, and just be using the default system information supplied in sys,path? Otherwise Gentoo will be very brittle. Of course, I can switch to root with 'su -' and leave the user's original environment behind...but I don't believe this is the norm (otherwise it should be the default), and I don't recall any Gentoo advice that one has to do 'su -' when installing ebuilds. There are all sorts of ways you can break portage by setting random environment variables. Just search for "portage environment" in bugzilla for some examples. That said, I suppose we could unset PYTHONPATH in some early phase in distutils-r1.eclass. Can anyone think of a reason NOT to do that? I can confirm that installation worked OK after su-ing with 'su -'. "There are all sorts of ways you can break portage by setting random environment variables. Just search for "portage environment" in bugzilla for some examples." To me this suggests that the Gentoo approach here could be more robust. There could be absolutely anything in the environment, but really Gentoo should install OK regardless. Clearly installation works with PYTHONPATH unset, so paying any attention to this variable is redundant, and is going to lead to random installation issues like the one I just experienced. It also looks like a bit of a security issue to me. I'm no expert, but if the admin user who does 'su' has got something malicious in his PYTHONPATH which is going to lead to a file being executed by Gentoo then this could be a problem. (In reply to Paul from comment #9) > To me this suggests that the Gentoo approach here could be more robust. > There could be absolutely anything in the environment, but really Gentoo > should install OK regardless. It's a 2-sided issue: sometimes it is very handy to be able to set an environment variable to control some behavior. Sometimes it breaks things. If you have some bright idea, please file a feature request bug or discuss it on the gentoo-dev mailing list. > It also looks like a bit of a security issue to me. I'm no expert, but if > the admin user who does 'su' has got something malicious in his PYTHONPATH > which is going to lead to a file being executed by Gentoo then this could be > a problem. That would be an issue regardless of portage; don't run su from an account which may be compromised.  commit c3c2f1823de4a8a9c479c2c874a846c4de30d3d9 Author: Justin Lecher <jlec@gentoo.org> Date: Thu Nov 12 10:26:21 2015 +0100 dev-python/cryptography: Drop vulnerable versions Gentoo-Bug: https://bugs.gentoo.org/show_bug.cgi?id=561696 obsoletes: Gentoo-Bug: https://bugs.gentoo.org/show_bug.cgi?id=561604 Gentoo-Bug: https://bugs.gentoo.org/show_bug.cgi?id=559648 Gentoo-Bug: https://bugs.gentoo.org/show_bug.cgi?id=521796 Package-Manager: portage-2.2.23 Signed-off-by: Justin Lecher <jlec@gentoo.org> https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=c3c2f1823de4a8a9c479c2c874a846c4de30d3d9 |