eval vs. exec

[holger krekel]

Delaney, Timothy wrote:
> > in python itself again. It is not a permanent service, it is not used
> > for mission critical stuff, and the people that are able to put stuff
> > from the external python into this environment without having 
> > references
> > to it probably won't bother. Maybe this is too optimistic, but It is
> > good enough for me. Currently the eval/exec thing is more interesting
> 
> You are too optimistic. Never assume anything is not a permanent service -
> everything will last longer than you intended, because people are afraid to
> change things that currently work. In many cases, this fear is justified.
> 
> Any time you are using code from an untrusted source you need to be
> incredibly careful. This includes third-party modules (I assume you trust
> the implementors of Python and its standard libraries ...). A trusted
> associate today may turn out to be a bitter ex-employee with a nasty
> backdoor into your systems in the future.

I've hear these type of arguments before. AFAIK bitter ex-employees
don't need to write some exec/eval-exploit, they just use their old
passwords or implant an easy backdoor on their last days. 

Todays company's practices regarding security are often a *laugh*. 
You try to close some mouses' hole but there are already several 
open six-lane highways into the core of your system. This doesn't 
neccessarily mean you don't need to care, though.

But assume that your application wants to give the system administrator
means to inspect and test the objects in a running application. I
wouldn't see the point of investing too much time on how to make it
'secure' (besides killing long-running mys-typed calculations). How
secure can using a debugger get? At least I often start
my python programs with 'python -i progname.py' which is a
good application of 'exec/eval'.

If your strings are coming from a public web-application 
it's a different matter, of course. But not everything is
a web-application.

regards,

    holger