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

D

Damjan

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

Christian Heimes

Damjan said:
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
 
G

Goldfish

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

Christian Heimes

Goldfish said:
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
 
P

Paul Boddie

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
 
D

Damjan

My question is, shoudn't it be enough to set PYTHONPATH and everything
I'm working on a PEP for a per user site dir for 2.6 and 3.0

great .. can't hardly wait.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top