Bug#493937: [Patch] Prevent loading of Python modules in working directory
James -
> >> 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]).
> >
> > I'm on FreeBSD. I used this test program:
> >
> > #include
> > #include
> > #include
> > #include
> >
> > main()
> > {
> >char buf[PATH_MAX];
> >char *s;
> >errno = 0;
> >buf[0] = 0;
> >s = realpath("", buf);
> >printf("errno = %d; s = %s; buf = %s\n", errno, s, buf);
> > }
> >
> > Result (when pwd is /tmp):
> >
> > errno = 0; s = /tmp; buf = /tmp
>
> errno = 2; s = (null); buf =
>
> > The definition of realpath() doesn't say what happens for an empty
> > string. It might handle it as "." or give an error.
>
> SUS does specify what should happen. It's an error. FWIW, I've filed a
> bug[0] against FreeBSD's behavior so we'll see what they think about it.
OK. It's good to have uniform behavior. Unspecified behavior is
annoying.
> > Did you test my proposed solution on Linux? I think it should work
> > everywhere.
>
> Yes, I did. It works fine.
Well, in that case I'll use this not-that-nice-but-works-everywhere
solution. Thanks for testing.
- Bram
--
hundred-and-one symptoms of being an internet addict:
270. You are subscribed to a mailing list for every piece of software
you use.
/// Bram Moolenaar -- [EMAIL PROTECTED] -- 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///
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#493937: [Patch] Prevent loading of Python modules in working directory
On Sat, Nov 15, 2008 at 6:52 AM, Bram Moolenaar <[EMAIL PROTECTED]> wrote:
>
> James -
>
>> 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]).
>
> I'm on FreeBSD. I used this test program:
>
> #include
> #include
> #include
> #include
>
> main()
> {
>char buf[PATH_MAX];
>char *s;
>errno = 0;
>buf[0] = 0;
>s = realpath("", buf);
>printf("errno = %d; s = %s; buf = %s\n", errno, s, buf);
> }
>
> Result (when pwd is /tmp):
>
> errno = 0; s = /tmp; buf = /tmp
errno = 2; s = (null); buf =
> The definition of realpath() doesn't say what happens for an empty
> string. It might handle it as "." or give an error.
SUS does specify what should happen. It's an error. FWIW, I've filed a
bug[0] against FreeBSD's behavior so we'll see what they think about it.
> Did you test my proposed solution on Linux? I think it should work
> everywhere.
Yes, I did. It works fine.
[0] - http://www.freebsd.org/cgi/query-pr.cgi?pr=128933
--
James
GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#493937: [Patch] Prevent loading of Python modules in working directory
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]).
I'm on FreeBSD. I used this test program:
#include
#include
#include
#include
main()
{
char buf[PATH_MAX];
char *s;
errno = 0;
buf[0] = 0;
s = realpath("", buf);
printf("errno = %d; s = %s; buf = %s\n", errno, s, buf);
}
Result (when pwd is /tmp):
errno = 0; s = /tmp; buf = /tmp
The definition of realpath() doesn't say what happens for an empty
string. It might handle it as "." or give an error.
> > 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
Did you test my proposed solution on Linux? I think it should work
everywhere.
- Bram
--
hundred-and-one symptoms of being an internet addict:
255. You work for a newspaper and your editor asks you to write an
article about Internet addiction...in the "first person."
/// Bram Moolenaar -- [EMAIL PROTECTED] -- 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///
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#493937: [Patch] Prevent loading of Python modules in working directory
On Fri, Nov 14, 2008 at 3:42 PM, Bram Moolenaar <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#493937: [Patch] Prevent loading of Python modules in working directory
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 -- [EMAIL PROTECTED] -- 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/// -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#493937: [Patch] Prevent loading of Python modules in working directory
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 <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Bug#493937: [Patch] Prevent loading of Python modules in working directory
James -
> > > Vim's python interface calls PySys_SetArgv with an argv[0] that doesn't
> > > resolve to a filename. This causes Python to prepend sys.path with an
> > > empty string which, due to Python's use of relative imports, allows the
> > > possibility to run arbitrary code on the user's system if a file in
> > > Vim's working directory matches the name of a python module a
> > > Python-using vim script tries to import.
> > >
> > > This should be fixed by Python 2.6 as it uses absolute imports by
> > > default, but I have not been able to test it. The attached patch fixes
> > > the problem in Vim by removing any empty strings from sys.path.
> >
> > I have now applied and tried this patch. It does not really work as
> > expected for me. Apparently the empty string in argv[0] is interpreted
> > as the current directory.
>
> argv[0] is used to seed the value that is prepended to sys.path.
>
> You can take a look at what PySys_SetArgv does at
> http://svn.python.org/view/python/branches/release25-maint/Python/sysmodule.c?rev=54836&view=markup
>
> What it boils down to in the simple case is checking for the existence
> of a path separator in argv0. If that doesn't exist, then a PyString is
> created from argv0 with size 0 and sys.path is prepended with that --
> empty string used for the first element of sys.path.
>
> > My first entry in sys.path is then the directory above the current
> > directory. The filter you added in the patch doesn't change anything.
>
> 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.
> You can also test it with the simple pytest.c that I've attached by
> specifying different arguments as the first element of the argv passed
> to PySys_SetArgv.
>
> $ gcc -o pytest $(python-config --cflags) $(python-config --ldflags) pytest.c
> $ ./pytest ''
> ['', '/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']
> $ ./pytest '/must>not&exist/bogusbinary'
> ['/must>not&exist', '/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']
> ['/must>not&exist', '/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']
>
> > For me it does work if I use:
> >
> >static char *(argv[2]) = {"/must>not&exist/ls", NULL};
> >
> > The first entry in path is then "/must>not&exist", which we can filter
> > out with:
> >
> >PyRun_SimpleString("import sys; sys.path = filter(lambda x: x !=
> > '/must>not&exist', sys.path)");
>
> This is just extra work for no gain.
It does work for me. Does it also work for you?
- Bram
--
hundred-and-one symptoms of being an internet addict:
249. You've forgotten what the outside looks like.
/// Bram Moolenaar -- [EMAIL PROTECTED] -- 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///
--
To UNSUBSC
Bug#493937: [Patch] Prevent loading of Python modules in working directory
On Wed, Nov 12, 2008 at 12:34:16PM +0100, Bram Moolenaar wrote:
>
> James -
>
> > Vim's python interface calls PySys_SetArgv with an argv[0] that doesn't
> > resolve to a filename. This causes Python to prepend sys.path with an
> > empty string which, due to Python's use of relative imports, allows the
> > possibility to run arbitrary code on the user's system if a file in
> > Vim's working directory matches the name of a python module a
> > Python-using vim script tries to import.
> >
> > This should be fixed by Python 2.6 as it uses absolute imports by
> > default, but I have not been able to test it. The attached patch fixes
> > the problem in Vim by removing any empty strings from sys.path.
>
> I have now applied and tried this patch. It does not really work as
> expected for me. Apparently the empty string in argv[0] is interpreted
> as the current directory.
argv[0] is used to seed the value that is prepended to sys.path.
You can take a look at what PySys_SetArgv does at
http://svn.python.org/view/python/branches/release25-maint/Python/sysmodule.c?rev=54836&view=markup
What it boils down to in the simple case is checking for the existence
of a path separator in argv0. If that doesn't exist, then a PyString is
created from argv0 with size 0 and sys.path is prepended with that --
empty string used for the first element of sys.path.
> My first entry in sys.path is then the directory above the current
> directory. The filter you added in the patch doesn't change anything.
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).
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']
You can also test it with the simple pytest.c that I've attached by
specifying different arguments as the first element of the argv passed
to PySys_SetArgv.
$ gcc -o pytest $(python-config --cflags) $(python-config --ldflags) pytest.c
$ ./pytest ''
['', '/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']
$ ./pytest '/must>not&exist/bogusbinary'
['/must>not&exist', '/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']
['/must>not&exist', '/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']
> For me it does work if I use:
>
>static char *(argv[2]) = {"/must>not&exist/ls", NULL};
>
> The first entry in path is then "/must>not&exist", which we can filter
> out with:
>
>PyRun_SimpleString("import sys; sys.path = filter(lambda x: x !=
> '/must>not&exist', sys.path)");
This is just extra work for no gain.
--
James
GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]>
#include
#include
int main(int argc, char **argv) {
int newargc = 1;
char *newargv[2] = {"", NULL};
if (2 != argc) {
fprintf(stderr, "Usage: %s \n", argv[0]);
return 1;
}
newargv[0] = argv[1];
Py_Initialize();
PySys_SetArgv(newargc, newargv);
PyRun_SimpleString("import sys; print sys.path");
PyRun_SimpleString("sys.path = filter(None, sys.path)");
PyRun_SimpleString("print sys.path");
return 0;
}
--- a/src/if_python.c
+++ b/src/if_python.c
@@ -530,6 +530,9 @@
if (PythonMod_Init())
goto fail;
+ PyRun_SimpleString("import sys; print sys.path");
+ PyRun_SimpleString("sys.path = filter(None, sys.path)");
+ PyRun_SimpleString("print sys.path");
/* the first python thread is vim's, release the lock */
Python_SaveThread();
signature.asc
Description: Digital signature
Bug#493937: [Patch] Prevent loading of Python modules in working directory
James - > > > Vim's python interface calls PySys_SetArgv with an argv[0] that doesn't > > > resolve to a filename. This causes Python to prepend sys.path with an > > > empty string which, due to Python's use of relative imports, allows the > > > possibility to run arbitrary code on the user's system if a file in > > > Vim's working directory matches the name of a python module a > > > Python-using vim script tries to import. > > > > > > This should be fixed by Python 2.6 as it uses absolute imports by > > > default, but I have not been able to test it. The attached patch fixes > > > the problem in Vim by removing any empty strings from sys.path. > > > > This is a Python bug, right? One should never add an empty entry to > > sys.path. And probably should not add a path relative to the executable > > anyway. > > Yes, it is a Python bug but it's one that they chose to ignore. The > code for PySys_SetArgv specifically adds the empty entry when it is not > able to resolve a filename (and therefore its parent directory). The > default use of absolute imports in Python 2.6 (assuming that also > affects their C interface) will only workaround the issue of empty > entries in sys.path. > > > Another solution would be to make the first argument to argv[] an > > absolute path, e.g. "/". Is there something against that? > > That still adds an unnecessary directory to sys.path. In the case of > Vim, I think the safest measure is to remove the extra entry from > sys.path. For other applications, where there is a directory from which > they want to load python plugins, it would make sense to add that > directory to sys.path. I suppose adding "/" won't break anything, but still isn't nice. Your solution indeed looks like the best solution. - Bram -- The CIA drives around in cars with the "Intel inside" logo. /// Bram Moolenaar -- [EMAIL PROTECTED] -- 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/// -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#493937: [Patch] Prevent loading of Python modules in working directory
On Mon, Nov 03, 2008 at 10:23:27PM +0100, Bram Moolenaar wrote: > > James - > > > Bram, > > > > Vim's python interface calls PySys_SetArgv with an argv[0] that doesn't > > resolve to a filename. This causes Python to prepend sys.path with an > > empty string which, due to Python's use of relative imports, allows the > > possibility to run arbitrary code on the user's system if a file in > > Vim's working directory matches the name of a python module a > > Python-using vim script tries to import. > > > > This should be fixed by Python 2.6 as it uses absolute imports by > > default, but I have not been able to test it. The attached patch fixes > > the problem in Vim by removing any empty strings from sys.path. > > This is a Python bug, right? One should never add an empty entry to > sys.path. And probably should not add a path relative to the executable > anyway. Yes, it is a Python bug but it's one that they chose to ignore. The code for PySys_SetArgv specifically adds the empty entry when it is not able to resolve a filename (and therefore its parent directory). The default use of absolute imports in Python 2.6 (assuming that also affects their C interface) will only workaround the issue of empty entries in sys.path. > Another solution would be to make the first argument to argv[] an > absolute path, e.g. "/". Is there something against that? That still adds an unnecessary directory to sys.path. In the case of Vim, I think the safest measure is to remove the extra entry from sys.path. For other applications, where there is a directory from which they want to load python plugins, it would make sense to add that directory to sys.path. -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]> signature.asc Description: Digital signature
