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 <l...@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 -- http://mail.python.org/mailman/listinfo/python-list
