Bug#493937: [Patch] Prevent loading of Python modules in working directory

[James Vega]

On Thu, Nov 13, 2008 at 11:23:07AM +0100, Bram Moolenaar wrote:
> 
> James -
> 
> > This is incorrect.  In Vim's current code, PySys_SetArgv is called with
> > an argv that is simply an empty string (and a terminating NULL
> > sentinel).  This causes sys.path's first element to be the empty string,
> > thus causing any Python import statements to use Vim's current working
> > directory as the first location to check for the requested module.
> > 
> > The filter specifically removes any elements in sys.path that evaluate
> > to false (i.e., the empty string).
> 
> That is not what happens for me.  Somehow somewhere the empty entry is
> changed to the full path of the directory above the current directory.
> I don't know where, but I see it happening.  I have tried this with:
> 
> 	:py import sys
> 	:py print sys.path
> 
> > Using the attached print_sys.path.diff, the following is printed when I
> > start Vim (the sys.path before and after my suggested filter() command):
> > 
> > ['', '/usr/lib/python2.5', '/usr/lib/python2.5/plat-linux2', '/usr/lib/python2.5/lib-tk', '/usr/lib/python2.5/lib-dynload', '/usr/local/lib/python2.5/site-packages', '/usr/lib/python2.5/site-packages']
> > ['/usr/lib/python2.5', '/usr/lib/python2.5/plat-linux2', '/usr/lib/python2.5/lib-tk', '/usr/lib/python2.5/lib-dynload', '/usr/local/lib/python2.5/site-packages', '/usr/lib/python2.5/site-packages']
> 
> As mentioned, for me the first entry is not '' but a path.   The filter
> command you suggested doesn't remove it.  I don't know where the
> difference between our systems comes from.

This is bizarre as I don't see how this could be happening in vanilla
Python code, so it seems like your install has been patched to add this
behavior.  Either way, I see two options:

1) Save sys.path before calling PySys_SetArgv and restore it afterward.
2) Prune the first element of sys.path after calling PySys_SetArgv.

We know that PySys_SetArgv always adds an element to the front of
sys.path and we know that we're giving it a value that isn't valid (to
prevent a segfault in some warn() function I can't find a reference to).

Adding an arbitrary, hopefully non-existent path in order to search for
and remove it just smells bad to me when there's defined behavior.  My
initial idea when I got this bug was to simply do 2) but I changed to
the filter() patch later to be (I thought) more robust.

I'd be interested in knowing where your Python install comes from so I
can see why it's behaving differently.

-- 
James
GPG Key: 1024D/61326D40 2003-09-02 James Vega <jamessan at debian.org>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
Url : http://lists.alioth.debian.org/pipermail/pkg-vim-maintainers/attachments/20081113/8ecf2092/attachment.pgp