Re: virtualpython / workingenv / virtualenv ... shouldn't this be part of python
>> My question is, shoudn't it be enough to set PYTHONPATH and everything >> automagically to work then? Is there some work done on this for python >> 3.0 or 2.6 perhaps? > > I'm working on a PEP for a per user site dir for 2.6 and 3.0 great .. can't hardly wait. -- damjan -- http://mail.python.org/mailman/listinfo/python-list
Re: virtualpython / workingenv / virtualenv ... shouldn't this be part of python
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
Re: virtualpython / workingenv / virtualenv ... shouldn't this be part of python
Goldfish 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. A malicious piece of software has already hundreds of way to overwrite modules. It could add a python executable to ~/bin and add ~/bin to PATH. it could modify .bashrc and add PYTHONPATH. Or it could drop some site.py and sitecustomize.py files in various directories. If you allow malicious or potential harmful software to write in your home directory you are lost. The new feature doesn't add new attack vectors. Christian -- http://mail.python.org/mailman/listinfo/python-list
Re: virtualpython / workingenv / virtualenv ... shouldn't this be part of python
On Jan 11, 11:45 am, Christian Heimes <[EMAIL PROTECTED]> wrote: > Damjan wrote: > > My question is, shoudn't it be enough to set PYTHONPATH and everything > > automagically to work then? Is there some work done on this for python 3.0 > > or 2.6 perhaps? > > I'm working on a PEP for a per user site dir for 2.6 and 3.0 > > Christian 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. -- http://mail.python.org/mailman/listinfo/python-list
Re: virtualpython / workingenv / virtualenv ... shouldn't this be part of python
Damjan wrote: > My question is, shoudn't it be enough to set PYTHONPATH and everything > automagically to work then? Is there some work done on this for python 3.0 > or 2.6 perhaps? I'm working on a PEP for a per user site dir for 2.6 and 3.0 Christian -- http://mail.python.org/mailman/listinfo/python-list
virtualpython / workingenv / virtualenv ... shouldn't this be part of python
There are several attempts to allow python to work with per user (or even per session) 'site-packages' like virtualpython / workingenv / virtualenv. But they all have their own shortcomings and quirks. My question is, shoudn't it be enough to set PYTHONPATH and everything automagically to work then? Is there some work done on this for python 3.0 or 2.6 perhaps? -- damjan -- http://mail.python.org/mailman/listinfo/python-list
