virtualpython / workingenv / virtualenv ... shouldn't this be part of python

[Paul Boddie]

On 11 Jan, 21:44, Goldfish <gregt... at mindspring.com> wrote:
>
> What about security holes, like a malicious version of socket getting
> downloaded into a user's directory, and overriding the default, safe
> version? Don't forget that in your PEP.

As Christian points out, there are various exploitable weaknesses
already, and running software as a particular unprivileged user is
clearly the anticipated way of limiting any damage caused, although
not (obviously) preventing that user's account from being trashed. Of
course, other solutions based on operating system features
(virtualisation, containers, jails) offer increased protection. In
order to try and offer per-user installation of system packages, I
started to write a solution called userinstall [1], although as I
descend deeper into Debian packaging, I note that it overlaps quite a
bit with a tool known as pbuilder [2], although that tool's purpose is
more oriented towards producing and testing packages in a cleanroom
environment.

There has been work on a sandboxed version of Python, and I'd argue
that such work complements the PEP mentioned above. But if you want
comprehensive control over potentially rogue processes, the operating
system is the thing you should look to for that control.

Paul

[1] http://www.boddie.org.uk/paul/userinstall.html
[2] http://packages.qa.debian.org/p/pbuilder.html