use of exec()

[lars van gemerden]

On Thursday, October 18, 2012 4:29:45 PM UTC+2, Chris Angelico wrote:
> On Fri, Oct 19, 2012 at 1:07 AM, lars van gemerden <lars at rational-it.com> wrote:
> 
> > Thanks, Chris,
> 
> >
> 
> > That works like a charm (after replacig "return ns.function" with "return ns['function']" ;-) ).
> 
> 
> 
> Err, yes, I forget sometimes that Python doesn't do that. JavaScript
> 
> and Pike both let you (though Pike uses -> instead of . for that
> 
> operator). Yes, Python has real methods on dictionary objects :)
> 
> 
> 
> > About the security, i noticed you can still import and use modules within the exec'ed code. Is there a way to prevent this or otherwise make this approach more secure.
> 
> 
> 
> Basically no, there's no real way to make it secure. Without
> 
> eliminating exec/eval, destroying insecurity is the hopeless work of a
> 
> wasted life, as the oracle said to Alice.
> 
> 
> 
> > I should say that the users that will be able to make custom functions, are not end-users, but authenticated designers, however i would like to close a backdoor to the whole framework.
> 
> 
> 
> You have to decide one thing: Will you permit them to execute
> 
> untrusted code on your system? If so, go ahead (and just warn them
> 
> that things like import shouldn't be done, as they can cause other
> 
> messes). I run a server that I build with the help of another guy (I
> 
> do the code, he does the bulk of the content - descriptions and
> 
> stuff), and I'm happy to trust him to not be malicious, so the purpose
> 
> of "embedded code in loci" is to make it easier to write tiny bits of
> 
> code, without any security requirement. But if you need security,
> 
> don't use eval. AT ALL.
> 
> 
> 
> There may be a brand new service coming along, though. The ast module
> 
> I think is getting a new evaluator that allows a little more
> 
> functionality than literal_eval, while still not permitting most
> 
> things. But you then have the question of performance, since you
> 
> effectively interpret the code at a high level.
> 
> 
> 
> ChrisA

I get your point, since in this case having the custom code option makes the system a whole lot less complex and flexible, i will leave the option in. The future customer will be informed that they should handle the security around the designers as if they were programmers. Aditionally i will probably add some screening for unwanted keywords (like 'import') and securely log any new/changed custom code including the designer account (must do that for other actions anyway).

Thanks again, Lars