Accessing global namespace

[John Roth]

"Carl Banks" <imbosol at aerojockey.invalid> wrote in message
news:Fclgb.27729$kD3.10907 at nwrdny03.gnilink.net...
> John Roth wrote:
> >
> > "Carl Banks" <imbosol at aerojockey.invalid> wrote in message
> > news:r%jgb.30366$541.25640 at nwrdny02.gnilink.net...
> >> John Roth wrote:
> >> >
> >> > "Tongu? Yumruk" <trooper at ttnet.net.tr> wrote in message
> >> > news:mailman.1065436150.27416.python-list at python.org...
> >> >> I'm trying to build a completely plug-in based system. One of my
> >> >> problems is importing a package dynamically. I'm trying to emulate
the
> >> >> import command. The __import__() function or imp module doesn't help
me
> >> >> much because they only return the module. I want to register the
module
> >> >> with it's name in the current namespace. I can do it by:
> >> >>
> >> >> globals()[module_name] = __import__(module_name)
> >> >>
> >> >> But I don't think it's a good thing to access the global namespace
> >> >> directly. I prefer using setattr() but I cannot access the current
> >> >> namespace as an object I want something like
> >> >>
> >> >> setattr(__main__,__import__(module_name))
> >> >>
> >> >> Is that possible? I'm using Python 2.1 on Debian Woody
> >> >
> >> > The easiest way to do a dynamic import is to build an
> >> > import statement and feed it into the exec statement.
> >>
> >>
> >> Also, the best way to make your program vulnerable to abuse.
> >>
> >> Use exec only if you explicit intend to give the user the option to
> >> input Python code, and only if the program is not running at a higher
> >> privledge level than the user is.
> >
> > Now, now. Did I say anything about accepting raw, unvalidated
> > input from the user? I certainly don't see anything about it in what
> > I said.
> >
> > There are pleanty of things I say that you can validly assail me for.
> > This doesn't happen to be one of them.
>
> You said nothing about raw, invaludated input, and that's the problem.
> Instead, you swept the potential little pitfall under the rug, and
> freely gave your advice to use exec as if one could use it without any
> care in the world.
>
> That's not only validly assailable, my friend, but asinine.
>
> I stand by what I said.  Using exec for anything other than explicitly
> asking the user for Python code is wrong, incorrect, and evil, with
> very few exceptions.  Even if it looks harmless.  Anyone who does
> that, or advises that, should be fired.

1. If you call me asinine, I'm not your friend. Apologize, or that stands.

2. One of the fundamental design principles for writing stable
(let alone secure) software is to validate user input. Some people
learn this sooner than others. To say what you said about exec
is simply short sighted. There are too many uses for generating
code internally and then using exec to compile it for that statement
to be anything other than (well, I'm not willing to characterize it
here.) In any case, asking the user for Python code to exec is
the last thing I would do, unless I was writing a command line
interpreter or some such.

2. As far as the pot calling the kettle black, I shouldn't need to
point out to you that using the global() function to stuff random,
unvalidated identifiers into your module namespace can be exploited
by the ungodly. That can, of course, be guarded against by validating
the user input, but then so can using exec.

At this point, I could simply cut and paste  your diatribe here,
and have it be a perfectly valid attack on your leading naive
newbies astray. I will, however, let you take that exercise should
you care to do so.

3. My original suggestion was to put the names in some other
data structure rather than in the module namespace. As far
as I know, that's the only secure method of handling it. Of
course, that's kind of swallowing camels while straining at
gnats since the entire objective of the exercise seems to be to
accept entire unvalidated modules into the application.

4. If you want to continue the pissing contest, go right ahead.
I don't particularly care to be known for my command of
intemperate language.

John Roth


>
>
> -- 
> CARL BANKS                   http://www.aerojockey.com/software
>