On 11 Jan, 21:44, Goldfish <[EMAIL PROTECTED]> 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 -- http://mail.python.org/mailman/listinfo/python-list
