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

[Bram Moolenaar]

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.

I'm using Python 2.5.  The implementation of PySys_SetArgv() uses
realpath().  It expands "" to the current directory.  I haven't looked
at the details, but I suspect that's what is causing the behavior I
notice.

You can see this file here:
http://svn.python.org/view/python/trunk/Python/sysmodule.c?rev=64856&view=markup

I think using a magic directory name works better than assuming
something about the python code, e.g. prepending an entry to sys.path.
A later version may correct the mistake and not change sys.path for an
empty string.  I think my version of the fix handles those situations.

- Bram

-- 
hundred-and-one symptoms of being an internet addict:
252. You vote for foreign officials.

 /// Bram Moolenaar -- Bram at Moolenaar.net -- http://www.Moolenaar.net   \\\
///        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\        download, build and distribute -- http://www.A-A-P.org        ///
 \\\            help me help AIDS victims -- http://ICCF-Holland.org    ///