[Python-Dev] Python 2.7.7. on Windows

[Steve Dower]

> Mike Miller wrote:
> On 04/29/2014 05:12 AM, Steve Dower wrote:
>> This would be an incredibly painful change that would surprise and
>> hurt a lot of people.
> 
> Hi, I think "incredibly painful" is overstating the case a bit. ;) We're talking
> about an installer default, a setting that would still be changeable as it
> always has, that by definition only will affect brand new installs.

Good point about it only affecting new installs, though that still constitutes a lot of installs.
 
>> Yes, it is possible for a non-admin user to install arbitrary packages
>> into a place where an admin user may inadvertently run it, thereby
>> providing escalation of privilege. On the other hand, that applies to
>> a lot of development tools, especially since most users on Windows
>> these days are actually limited administrators - ANYTHING they install
>> could run when they elevate a certain process.
> 
> None of Microsoft's Dev tools install to C:\, rather to ProgramFiles. The fact
> that another security issue may exist is not a good justification for creating
> additional.

The fact that the mitigations are well known by the people who have to worry about them is a good justification for not creating a compatibility issue. It's easy for IT admins to install Python in a way that the files are read-only, the .pyc and .pyo files are already there, and user site packages will be used by default (I think that last one is easy?). The good IT admins even know that they need to do this - perhaps we can help educate the bad admins? (FWIW, if you have admin privileges on your own machine, YOU are the IT admin. Are you a good one or a bad one?)

>> On the other hand, Python from python.org is a tool that should only
>> be installed by those who are prepared to manage it. On Windows it is
>> easy enough to have a second, secured copy for your admin scripts and
>> an unsecured copy for non-admin tasks.
> 
> This sounds like the perspective of someone highly technical, forgetting that
> new users will be installing python as well and vastly outnumber us. "Normal
> people" need help to avoid security issues.

One place where mitigations are added are the distributions (Canopy, Anaconda, etc.). These packages redistribute Python and install to different locations with different permissions (I'm not promising that they all do it properly, but they have the opportunity to do so). The reference implementation of CPython is typically not the best option for "normal people", who are much better served by one of these bundles.

> Microsoft's guidelines on where to install software are clear, and don't make
> exceptions that "tools" should be installed to the root of the drive to bypass
> file system permissions, for convenience.

I'm well aware of the guidelines, hence the practicality vs. purity comment. I'm fairly certain that the installation to the root was originally about ease of command-line access rather than bypassing permissions - the permissions probably didn't exist for the first few versions of Python (Python for DOS obviously didn't care... maybe it's always been about backwards compatibility?)

At this point, installing into the root is about not breaking everyone who *knows* that Python installs into the root directory and always has. 

>> I'm not sure what change you are proposing here... doesn't the
>> installer already have an option to add to PATH? I'm sure I keep disabling it.
> 
> No, it does not. Unless it got slipped in when I wasn't looking.
> 
> It should be an option though, I think everyone would agree.

Thanks Brett for pointing out that it arrived in Python 3. I'm sure it would be an acceptable addition to 2.7.7, though you'd need to get it in before RC and you'd also need to find someone who is keen and able to keep making 2.7 installers for Windows. Right now, we don't have anyone who is both.

>> "python.exe" on my PATH because I have 10+ versions installed at any
>> one time.
> 
> Remember, python-dev's are not the target users of this package, and are a
> rather minuscule fraction of the user base.

My day job revolves around making Python easier to use for non "python-dev"s, especially those who have multiple versions of Python installed simultaneously (as I mentioned, over 50% of our user base). Having PATH or PATHEXT set globally is a source of much confusion. (Though a global PYTHONPATH causes more problems, but that isn't part of this discussion.)

>> Python installation. At this point, 2.7.6->2.7.7 should be an
>> incredibly safe upgrade, and there's no way to safely change the
>> default installation location
> 
> This would continue to be the case, as the installer will recognize the
> previously installed Python 2.7 and use its setting. This should affect only
> *brand new installs.*

For example, next time you redeploy your hosted service on a clean VM with the latest security patches? The next time someone does a clean uninstall-reinstall because they've been burned by upgrades before? The next time someone arrives at work and IT has given them a new image and Python is "gone"? I can guarantee that you will break someone

>> or the ACLs on the install directory.
> 
> No ACLs would be affected or changed or even thought about. Simply installing to
> the correct folder (on new installs) will accomplish the goal.

The effective permissions change, and now commands that didn't require elevation do. Tools that didn't need to be manifested for UAC have to be recompiled. Scripts that used to work will simply break. This is the problem, not whether the permissions are explicitly set as part of the install process.

> In short, this design of restricted permissions (read-only) for binaries and
> PATH conveniences goes back decades under Unix and other OS's. MS Windows has
> finally caught up in the security department in the last few releases. Please
> don't keep us back in the "bad old days" of DOS where everything was installed
> to the root folder.

My employer would be most unhappy if I wasn't trying to encourage good Windows support :)

At the same time, my employer, colleagues, friends, collaborators and most people on python-dev would all be unhappy if I made everyone angry at Python. At risk of saying it too often, practicality beats purity.

Cheers,
Steve

> --
> -Mike
>