On 7/7/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
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.

My plan is no.  As Guido said, getting this right is  feasibly questionable.  I do not plan on trying to have security proxies or such implemented in Python code; it will need to be in C.  If someone comes along and manages to find a way to make Python work without significantly changing the languages, great, and we can toss out my security implementation for that.

But as of right now, I am not planning on making Python code safe to run in Python code.

-Brett

--
--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/brett%40python.org

_______________________________________________
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

Reply via email to