What's so wrong about execfile?

[Carl Banks]

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