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 <pavlovevide...@gmail.com>wrote:
> On Feb 27, 7:21 pm, Sammo <sammo2...@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...@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/
--
http://mail.python.org/mailman/listinfo/python-list
