So it isn't a trivial repro, which means there is some more context required from anyone who sees this issue.
I personally would be looking at the ACLs of the files that can't be accessed. I expect to see that they are not inheriting permissions from their parent and probably only have read-only permissions for whoever installed - this is easy to check, because the user won't be able to open the file in any other program either (or look at the permissions for that matter...). The admin user will be able to see them and restore them. The "logic" in setuptools/pip/distutils/setup.py/whoever that may lead to this is "these files should _really_ be read-only" and so they reset all permissions and give the current user read access. If the administrative user is the current user (which is pretty normal for Windows these days, because even the admins spend most of their time restricted), this is fine for a single-user system. However, where the admin user is a separate account (name/SID) from the interactive user, this will result in the normal user being denied even read access. My testing (with pip install flake8 in Python 2.7.6 64-bit) didn't show anyone changing the permissions on any files. However, it is possible that the user has manually secured their Python install (else why would they be running pip install as admin?). AFAICT, Python 2.7 doesn't provide a way in the stdlib to change ACLs (os.chmod is totally restricted to the read-only flag, which isn't the problem here), and I didn't see anything in pip or setuptools that could do it (though setuptools will use pywin32 if it is there - it didn't seem related, but I also didn't test with it installed). My specific questions for the user would be: * Is your administrator account a different account from the one you normally log in with? (Alternatively, do you see the UAC dialog appear? Do you have to type a password or do you just click "Yes"?) * Can you open the file in Notepad or equivalent? * If you run "cacls <filename>" as administrator, what is the output? * If you run "cacls C:\Python27\python.exe", what is the output? This sort of case is the best argument for secure-by-default installations into Program Files - no installer should even have to think about messing with ACLs. The current CPython installers support this sort of install if you change the directory, but maybe it is time for pip/setuptools to start assuming that user site-packages is the default on Windows so we could actually consider changing the default Python install location? (If anyone really wants to dive into that discussion again, go ahead and change the subject line :) ) Cheers, Steve Steve Dower wrote: > My guess would be that something is setting permissions for the current user, > and these installs were done by an admin user who is not the current user. > This > will result in explicit permissions on the file that may deny read access. > > I'll have to confirm tomorrow. Do you have the exact versions of setuptools > and pip that are problematic? (My guess is that it won't matter. The code has > probably been in there for a while if I'm right.) > > Cheers, > Steve > >> From: Ian Cordasco >> Sent: 5/5/2014 17:27 >> To: Distutils list >> Subject: [Distutils] Windows 8 pkg_resources permissions bug >> Hey all, >> >> I searched the issues on the setuptools repository but I couldn't find >> any that seemed relevant to what a user of Flake8 has run into: >> https://bitbucket.org/tarek/flake8/issue/142/installation-on-windows-8-permissions >> >> It seems that installing something that relies on pkg_resources to >> load plugins will cause errors on Windows 8. Does anyone have any >> insight? Is this actually a bug? Are we just using pkg_resources >> incorrectly? >> >> Thanks in advance, >> Ian _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
