[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.python

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

?????? ???????????

1/11/2008 4:24:00 PM

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
5 Answers

Christian Heimes

1/11/2008 4:45:00 PM

0

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

gregturn

1/11/2008 8:44:00 PM

0

On Jan 11, 11:45 am, Christian Heimes <li...@cheimes.de> 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.

Christian Heimes

1/11/2008 8:55:00 PM

0

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

Paul Boddie

1/12/2008 12:02:00 AM

0

On 11 Jan, 21:44, Goldfish <gregt...@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/userin...
[2] http://packages.qa.debian.org/p/pbu...

?????? ???????????

1/15/2008 8:57:00 AM

0

>> 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