On 7/8/06, Ka-Ping Yee <[EMAIL PROTECTED]> wrote: > The situation you're describing here is a classic case of one > component keeping a closely held authority while using it to > provide some limited capability to some other component. This > comes up quite often when you're trying to write secure code. > > If you want to be able to write that subsystem in Python, then > we will need a way to create airtight Python objects (i.e. objects > that only leak what they explicitly choose to leak). > > So this goes back to the big question of goals: > > Do we want to be able to protect one piece of Python code > from another piece of Python code? > > I'd like the answer to be yes. It sounded for a while like this > was not part of Brett's plan, though. Now i'm not so sure. It > sounds like you're also interested in having the answer be yes? > > Let's keep talking about and playing with more examples -- i think > they'll help us understand what goals we should aim for and what > pitfalls to anticipate before we nail down too many details.
I'd like the answer to be no, because I don't believe that we can trust the VM to provide sufficient barriers. The old pre-2.2 restricted execution mode tried to do this but 2.2 punched a million holes in it. Python isn't designed for this (it doesn't even enforce private attributes). I guess this is also the main reason I'm skeptical about capabilities for Python. -- --Guido van Rossum (home page: http://www.python.org/~guido/) _______________________________________________ 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
