What's so wrong about execfile?

[James Matthews]

It is considered one of the big holes in PHP (Remote file include...)
However in Python things can be done securely

On Sat, Feb 28, 2009 at 7:15 AM, Carl Banks <pavlovevidence at gmail.com>wrote:

> On Feb 27, 7:21 pm, Sammo <sammo2... at gmail.com> wrote:
> > Given that execfile has been removed in py3k, I want to understand
> > exactly why.
> >
> > Okay, I get that execfile is bad from the following thread:
> >
> > On Jul 29 2007, 2:39 pm, Steven D'Aprano
> >
> >
> >
> > <st... at REMOVE.THIS.cybersource.com.au> wrote:
> > > (1) Don't use eval, exec or execfile.
> >
> > > (2) If you're an expert, don't use eval, exec or execfile.
> >
> > > (3) If you're an expert, and are fully aware of the security risks,
> don't
> > > use eval, exec or execfile.
> >
> > > (4) If you're an expert, and are fully aware of the security risks, and
> > > have a task that can only be solved by using eval, exec or execfile,
> find
> > > another solution.
> >
> > > (5) If there really is no other solution, you haven't looked hard
> enough.
> >
> > > (6) If you've looked REALLY hard, and can't find another solution, AND
> > > you're an expert and are fully aware of the security risks, THEN you
> can
> > > think about using eval, exec or execfile.
> >
> > What are some of the reasons why execfile should not be used?
> >
> > What are some examples of cases where execfile is the correct way of
> > doing something?
>
> You didn't quote the context of Steven's reply, so I don't know if he
> was talking in general, or for a particular situation.  I suspect it
> was the latter, though.
>
> Anyway, there is one generally valid use case for these three: when
> it's your deliberate intention to give the user the power to run
> arbitrary Python code.  If you really want to give the user this
> power, and the user is trusted on whatever machine they are running it
> on, go ahead and use it.  No apology necessary.
>
> [For instance, the package I use to generate my web site uses exec and
> eval, because it processes templates with embedded Python code.  It's
> all generated statically, on my own desktop, and I author all the
> pages myself, so there is no security risk.  If I were to distribute
> this package (and I do, though not many people use it, because
> everyone just writes their own HTML templates), there would be no risk
> because the user is expected to be able to run Python, and if they can
> be trusted to run Python on their own system, they can be trusted to
> run my program, which execs templates that they write themselves.]
>
> I would suggest, however, that even if that is your intention that you
> consider leveraging Python's built-in import infrastructure.  Instead
> of execfile, you could have your program simply import a module the
> user writes (after adding a user-specific directory to sys.path).
>
>
> Now, here are a few situations where you should follow Steven's advice
> above (i.e., don't, ever):
>
> - Don't ever use exec or eval to construct a variable name
> dynamically.  Don't ever do this, for instance:
>
> x = eval("self","%s%d" % (name,index))
>
> This is unforgiveable.  Python has better and safer ways to do this
> (use getattr, setattr, globals, and locals built-ins).  And if you
> find yourself using them a lot, it's a red flag that you should be
> using dicts instead.
>
> - Don't ever pass any data to exec or eval that you didn't either
> write, or thoroughly inspect, yourself.  Especially don't pass it any
> data you received over the network.  You have to be the super extreme
> expert that Steven described, and own a lot of liability insurance,
> befor you can do that.
>
>
> Carl Banks
> --
> http://mail.python.org/mailman/listinfo/python-list
>



-- 
http://www.goldwatches.com/

http://www.jewelerslounge.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-list/attachments/20090228/4b7117a7/attachment-0001.html>