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

Discussion in 'Python' started by Damjan, Jan 11, 2008.

  1. Damjan

    Damjan Guest

    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, Jan 11, 2008
    #1
    1. Advertisements

  2. I'm working on a PEP for a per user site dir for 2.6 and 3.0

    Christian
     
    Christian Heimes, Jan 11, 2008
    #2
    1. Advertisements

  3. Damjan

    Goldfish Guest

    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.
     
    Goldfish, Jan 11, 2008
    #3
  4. 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
     
    Christian Heimes, Jan 11, 2008
    #4
  5. Damjan

    Paul Boddie Guest

    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
     
    Paul Boddie, Jan 12, 2008
    #5
  6. Damjan

    Damjan Guest

    My question is, shoudn't it be enough to set PYTHONPATH and everything
    great .. can't hardly wait.
     
    Damjan, Jan 15, 2008
    #6
    1. Advertisements

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 (here). After that, you can post your question and our members will help you out.