Christian Ullrich added the comment:
Actually, this appears to be fixed in pip 1.5.6 (and 1.5.5, commit
79408cbc6fa5d61b74b046105aee61f12311adc9, AFAICT), which is included in 3.4.1;
I cannot reproduce the problem in 3.4.1. That makes this bug obsolete.
--
Donald Stufft added the comment:
I believe in pip 1.5.6 we switched from shutil.move to shutil.copytree which I
believe will reset the permissions/SELinux context?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21030
Martin v. Löwis added the comment:
Christian: thanks for the update. It's actually that the bug is fixed, not
obsolete :-)
--
resolution: - fixed
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21030
Nick Coghlan added the comment:
A little additional explanation of why the switch to copytree would have
fixed this, at least in the SELinux case: under SELinux, files typically
get labelled with a context based on where they're created. Copying creates
a *new* file at the destination with the
Martin v. Löwis added the comment:
If this needs to be done by fixing the ACLs afterwards, then I suggest to add a
C custom action, based on the code in
http://stackoverflow.com/questions/17536692/resetting-file-security-to-inherit-after-a-movefile-operation
--
title: pip usable only
Christian Ullrich added the comment:
According to procmon, ensurepip first installs the bundled packages in $TEMP,
then moves the resulting files to the Python installation directory. According
to http://support.microsoft.com/kb/310316, a file that is moved within the same
volume keeps its
Martin v. Löwis added the comment:
I agree with the analysis. Notice that this may sound worse than it is: even if
a regular user could run pip, they still couldn't install anything. As users
will have to get an elevated prompt, anyway, when running pip, they typically
won't notice the
Christian Ullrich added the comment:
Unprivileged users cannot install into the global site-packages, but they might
want to use the global pip to install with --user.
Also, this issue affects not only pip, but also the other bundled packages,
i.e. setuptools and pkg_resources.
--
Nick Coghlan added the comment:
The current approach is also likely to cause problems under SELinux.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21030
___
Nick Coghlan added the comment:
Solution 1 will also handle the SELinux case (copy and then delete original).
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21030
___
New submission from Christian Ullrich:
After installing python-3.4.0.amd64.msi on Windows 8.1 x64, the pip command
(and the versioned ones as well) only work for administrators. Regular users
get this:
Traceback (most recent call last):
File C:\Program Files\Python34\lib\runpy.py, line 171,
Changes by Ned Deily n...@acm.org:
--
nosy: +loewis, zach.ware
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21030
___
___
Python-bugs-list
12 matches
Mail list logo
