On 7/12/06, Jim Jewett <jimjjewett at gmail.com> wrote: > > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/python-dev/attachments/20060712/98b621f6/attachment.html
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