Title: pip usable only by administrators on Windows and SELinux
Type: behavior Stage:
Components: Installation, Windows Versions: Python 3.4
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: Nosy List: chrullrich, dstufft, loewis, ncoghlan, zach.ware
Priority: normal Keywords:

Created on 2014-03-23 00:25 by chrullrich, last changed 2014-06-23 23:30 by ncoghlan. This issue is now closed.

Messages (11)
msg214527 - (view) Author: Christian Ullrich (chrullrich) * Date: 2014-03-23 00:25
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\", line 171, in _run_module_as_main
    "__main__", mod_spec)
  File "C:\Program Files\Python34\lib\", line 86, in _run_code
    exec(code, run_globals)
  File "C:\Program Files\Python34\Scripts\pip.exe\", line 5, in <module>
ImportError: cannot import name 'main'

The immediate reason is that the files in the site-packages/pip directory are created with no access permissions for non-administrators:

C:\Program Files\Python34\Lib\site-packages\pip>icacls NT-AUTHORITY\SYSTEM:(F)

Why that is, I have no idea. It can be fixed by running:

icacls path\to\site-packages\pip /inheritance:e /t
icacls path\to\site-packages\pip /reset /t

The /reset may be unnecessary.
msg214548 - (view) Author: Christian Ullrich (chrullrich) * Date: 2014-03-23 06:34
According to procmon, ensurepip first installs the bundled packages in $TEMP, then moves the resulting files to the Python installation directory. According to, a file that is moved within the same volume keeps its original ACL and does not inherit permissions from its new parent directory.

I can think of two ways to fix this:

1. Instead of moving the files, copy them (and delete the originals)
2. Reset the ACLs after the move. The icacls commands I posted earlier
   will work, but icacls may not be available with the same option set
   on all supported Windows versions.

Of the two, #1 is probably more reliable.
msg214551 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2014-03-23 08:09
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 problem.

In any case, I also think that the problem is within ensurepip.
msg214552 - (view) Author: Christian Ullrich (chrullrich) * Date: 2014-03-23 08:23
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.
msg214567 - (view) Author: Nick Coghlan (ncoghlan) * (Python committer) Date: 2014-03-23 12:23
The current approach is also likely to cause problems under SELinux.
msg214568 - (view) Author: Nick Coghlan (ncoghlan) * (Python committer) Date: 2014-03-23 12:25
Solution 1 will also handle the SELinux case (copy and then delete original).
msg221312 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2014-06-22 21:03
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
msg221354 - (view) Author: Christian Ullrich (chrullrich) * Date: 2014-06-23 13:27
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.
msg221365 - (view) Author: Donald Stufft (dstufft) * (Python committer) Date: 2014-06-23 15:35
I believe in pip 1.5.6 we switched from shutil.move to shutil.copytree which I believe will reset the permissions/SELinux context?
msg221370 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2014-06-23 17:43
Christian: thanks for the update. It's actually that the bug is fixed, not obsolete :-)
msg221384 - (view) Author: Nick Coghlan (ncoghlan) * (Python committer) Date: 2014-06-23 23:30
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 correct context for that location
(based on system policy), but moving an *existing* file will retain its
*original* context - you then have to call "restorecon" to adjust the
context for the new location.

I assume Windows NTFS ACLs are similar, being set based on the parent
directory at creation and then preserved when moved.

Moral of the story? These days, if you're relocating files to a different
directory, copying and then deleting the original will be significantly
more consistent across different environments. OS level move operations are
best avoided in cross platform code, unless it's within the same directory,
or you really need the speed and are prepared to sort out the relevant
access control tweaks afterwards.
Date User Action Args
2014-06-23 23:30:10ncoghlansetmessages: + msg221384
2014-06-23 17:43:56loewissetstatus: open -> closed
resolution: fixed
messages: + msg221370
2014-06-23 15:35:32dstufftsetmessages: + msg221365
2014-06-23 13:27:43chrullrichsetmessages: + msg221354
2014-06-22 21:03:46loewissetmessages: + msg221312
title: pip usable only by administrators on Windows -> pip usable only by administrators on Windows and SELinux
2014-03-23 12:25:02ncoghlansetmessages: + msg214568
2014-03-23 12:23:48ncoghlansetmessages: + msg214567
2014-03-23 08:23:36chrullrichsetmessages: + msg214552
2014-03-23 08:09:48loewissetnosy: + ncoghlan, dstufft
messages: + msg214551
2014-03-23 06:34:27chrullrichsetmessages: + msg214548
2014-03-23 02:32:50ned.deilysetnosy: + loewis, zach.ware
2014-03-23 00:25:44chrullrichcreate