On 7/12/06, Jim Jewett <[EMAIL PROTECTED]> wrote:
As Bob said, "crash" means segfaulting the Python proceess. Can't exactly save yourself from that one easily. =)
From an initial design point it is. It is an assumption I want to be able to make about the design. If we can come up with a reasonable way for it to work, great. But to begin with, I am assuming objects created within an interpreter will not be passed into another one.
Security reasons. If I can get a Python object in other interpreter with more rights to do something for me I have a serious problem.
Do realize that things assumed might have to be made true as much as possible. And in my Threat Model list, I have the caveat that C extension modules are exempt from this.
This one is not in my Threat Model.
I am going with your latter assumption in my design.
-Brett
Ka-Ping Yee writes:
> A. The interpreter will not crash no matter what Python code
> it is given to execute.
Why?
We don't want it to crash the embedding app (which might be another
python interpreter), but if the sandboxed interpreter itself crashes,
is that so bad? The embedding app should just act as though that
interpreter exited, possibly with a status code.
As Bob said, "crash" means segfaulting the Python proceess. Can't exactly save yourself from that one easily. =)
> B. Python programs running in different interpreters embedded
> in the same process cannot communicate with each other.
Why not? Can't eavesdrop, yes. Can't force a connection, so that
the other interpreter is free to ignore them. Maybe even make it
lockable, like sockets -- but it isn't something worth promising.
From an initial design point it is. It is an assumption I want to be able to make about the design. If we can come up with a reasonable way for it to work, great. But to begin with, I am assuming objects created within an interpreter will not be passed into another one.
> C. Python programs running in different interpreters embedded
> in the same process cannot access each other's Python objects.
Note that Brett's assumption of shared extension modules violates this
-- but I'm not sure why he needs to assume that. (Because of the
init-only-once semantics, I'm not even sure it is a good idea to share
them.)
Security reasons. If I can get a Python object in other interpreter with more rights to do something for me I have a serious problem.
Do realize that things assumed might have to be made true as much as possible. And in my Threat Model list, I have the caveat that C extension modules are exempt from this.
> D. A given piece of Python code cannot access or communicate
> with certain Python objects in the same interpreter.
Why not? Is this just a way of allowing lightweight subinterpreters?
Or do you really mean that they can't replace or modify certain
objects, such as the permission-controlling code?
This one is not in my Threat Model.
> E. A given piece of Python code can access only a limited set
> of Python objects in the same interpreter.
Does this include objects it creates? Or are you just saying that it
will behave as if its builtins were segregated, and not see changes
made by another interpreter?
I am going with your latter assumption in my design.
-Brett
_______________________________________________ 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
