Guido van Rossum wrote: >>It would be a lot better if we could get away from the idea >>of a "restricted mode" in the sense of a flag somewhere that >>a bunch of things have to take notice of in order to behave >>securely, because that model of security is prone to springing >>leaks -- as happened in a big way when new-style classes were >>introduced. > > > Right. Restricted mode currently uses both paradigms: you only have > access to the builtins that are given to you in the __builtins__ dict > -- this is pure capability stuff, and IMO it works well -- and some > builtin operations behave differently when you're in restricted mode > -- this is the ACL stuff, and Samuele revealed serious holes in it. What if instead of 'builtin behaves differently in restricted mode' we had 'restricted __builtins__ contains a DIFFERENT builtin, that happens to have the same name'? That is, in addition to the ability to simply deny access to a specific builtin function or class, there was the ability to _replace_ one before giving it to the restricted code. Regards, Nick. -- Nick Coghlan | Brisbane, Australia Email: ncoghlan at email.com | Mobile: +61 409 573 268
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4