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

James Vega jamessan at debian.org
Fri Nov 14 21:40:00 UTC 2008


On Fri, Nov 14, 2008 at 3:42 PM, Bram Moolenaar <Bram at moolenaar.net> wrote:
>
> James -
>
>> 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.

Then this appears to be a difference (bug?) in your libc.  This is not
the case with glibc 2.7 or 2.8 (the two systems I can currently test
on).  Those error with ENOENT (as specified by SUS[0]).

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

This is one of the express purposes of PySys_SetArgv, as I mentioned
earlier.  The Python developers have stated multiple times[1][2] that
they consider the sys.path adjustment to be intended behavior and the
actual bug is implicit relative imports instead of defaulting to
absolute imports and using relative imports when requested.

Either way, thanks for pointing out the issue about using a buggy libc.
I'll keep that in mind when I push patches to other projects.

[0] - http://www.opengroup.org/onlinepubs/009695399/functions/realpath.html
[1] - http://bugs.python.org/issue946373
[2] - http://lists.gnu.org/archive/html/emacs-devel/2008-09/msg00215.html

-- 
James
GPG Key: 1024D/61326D40 2003-09-02 James Vega <jamessan at debian.org>





More information about the pkg-vim-maintainers mailing list