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

Bram Moolenaar Bram at moolenaar.net
Sat Nov 15 11:52:49 UTC 2008


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 <stdio.h>
#include <sys/param.h>
#include <stdlib.h>
#include <errno.h>

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





More information about the pkg-vim-maintainers mailing list