On 8/14/10 5:36 PM, Christian Heimes wrote: >> For example, when you go to save your bit of code, it will go in and if >> it finds __ anywhere in the text it just replaces it with xx. And, since >> getattr is not available, '_' + '_' won't get you anywhere. > > That's not as secure as you might think. First of all you can write "_" > in more way than you may think.
Well yes, I know-- but as I said in the original post, eval, exec, compile, getattr and such, are all unavailable. So its possible someone can write '_' in various ways (though I'm disallowing both chr and unichr for entirely different reasons), and they can even put them together so that there's a __ as a string in some variable, I can't find any way in which they would then be able to get to get a special method. Namely, type.__subclasses__ or object.__getattribute__. They can't enter any code which does blah.__class__, and they can't construct a string through twisty ways to then do getattr(blah, twisty) where twisty = "__class__". > If you have access to eval, exec or compile you can easily work around > your restrictions: I think its pretty much a given that if you're even trying to do some kind of restricted sandbox, eval and the like are the first things to go. :) > As you can see, black listing isn't the best approach here. But I have a two pronged strategy: the black list is only half of the equation. One, I'm blacklisting all the meta functions out of builtins. Eval, compile, getattr, and such. Then, I'm doing some blatant textual munging, making it so someone can not access any __special__ methods, or use exec. -- Stephen Hansen ... Also: Ixokai ... Mail: me+list/python (AT) ixokai (DOT) io ... Blog: http://meh.ixokai.io/
signature.asc
Description: OpenPGP digital signature
-- http://mail.python.org/mailman/listinfo/python-list
