On Thu, Jun 29, 2006 at 11:48:36AM -0700, Brett Cannon wrote: > My worry, as has been from the start, is containing 'file'. The ``del > __builtins__`` bug for 'rexec' started me as skittish towards hiding stuff > from the built-in namespace. And knowing how easy it tends to be to get at > objects and types in Python in general makes me worry even more about hiding > objects and types properly from people (within reason, of course; if you
Random, only tangentially-related thought: what if each interpreter had a blacklist of objects that should never be made available to untrusted code? You could then put __builtins__, file, and anything else on this list. Then, using some #ifdef'ery in ceval.c, check if an object is on this blacklist before pushing it onto the evaluation stack; if it's a blacklisted object, replace it with None (or raise an exception). This entails a performance hit and makes it impossible to support Bastion-like functionality, where untrusted code could call code that would be treated as trusted, but it also means that, even if you find some type(foo).__dict__['blah'].co_magic incantation that lets you get to a dangerous type object or module, it wouldn't matter because the dangerous value is silently substituted, and the untrusted code has no way of breaking out of this. (Could you fool a C extension into doing stuff with a dangerous object? Don't know...) This thought was sparked by the piece on failure-oblivious computing in today's Linux Weekly News about this paper: http://www.usenix.org/events/osdi04/tech/rinard.html. The authors tried continuing to run after a memory error instead of segfaulting: out-of-bounds writes were ignored, and OOB reads returned generated values. See the LWN discussion for more (subscribers only). --amk _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com