Mike Miller wrote: > I thought this might be a good time to make a final plea to fix a > long-standing security issue in the installer on Windows. By default it > installs > Python to the root folder, thereby bypassing filesystem permissions: > >http://bugs.python.org/issue1284316
This would be an incredibly painful change that would surprise and hurt a lot of people. Mark Hammond's last comment on the linked issue sums up my view as well: "My take is still that Python is a tool, not an app. People writing an app they wish to distribute using Python should include Python in their package (ie, not rely on an installed version) and these apps should conform with the guidelines." 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. I'm all for encouraging apps to redistribute Python (as most do on Windows). In this case, they can easily apply the correct security settings, typically by installing pythonxy.dll with their application and ignoring any global settings (PYTHONPATH, registry keys, etc.). 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. > The main rationale given (for not using the standard %ProgramFiles%) has been > that the full path to python is too long to type, and ease of use is more > important than the security benefits given by following Windows conventions. > > However, adding python to the PATH variable is an alternative solution that > would result in even fewer keystrokes needing to be typed at a console, while > maintaining system security. > > As this is an installer setting and not a code change, I gather that the > opportunities for code breakage should be fewer. Please consider updating this > setting to a more secure and friendly default, for 2.7.7 and 3.5+ as well. 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. I don't want "python.exe" on my PATH because I have 10+ versions installed at any one time. I have my own set of aliases because even the py.exe launcher can't handle my setup :) The info we've gotten from our users (Python Tools for Visual Studio) shows that most have two or more versions of Python installed, so having one or both of them in PATH or PATHEXT just adds ambiguity. The other rationales are .pyc generation and package installation. Unlike PATH, these are not red herrings, but they do only apply to developers and not end users (where the developer has done his/her job properly). Speaking as the one who is likely to take over from Martin as the Windows build manager (the only people arguing so far are my employer's lawyers, but I'm winning that argument), I don't see any change that can be made to 2.7.7 apart from adding a link in the installer to a documentation page on how to secure the 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 or the ACLs on the install directory. As for 3.5, I have some ideas that I will raise with python-dev once I've had a chance to think through all the issues (think proper per-user installs, redist modules, etc.). More secure installations would certainly be on the table, but practicality very easily beats purity here IMHO. Cheers, Steve _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
