Question on multiple Python users in one application

[Loren Wilton]

> Okay. Before you go one micron further, answer this critical question:
>
> *Do you trust your users?*

The basic answer is yes. This program amounts to a virtual machine 
implementation of a multi-processor and multi-user mainframe computer. It 
runs on a Windows box of its own. It has an IO subsystem of its own with a 
pretty hefty firewall machine in front of it before it gets to internet 
access. The Windows OS doesn't have network access at all. That may sound 
like a joke to you, but some of the biggest companies in the world have this 
machine running in their back rooms.

> Would you permit your users to have complete access to the computer
> that this program is running on? If they're all people in the same
> company, running something on the company's own server, you're fine.
> But if there's even the slightest chance that a malicious user will be
> on this system, you MUST NOT permit arbitrary code. CPython is *not* a
> secured environment.

This is understodd and accepted. I should say at the moment this is at the 
feasibility and experimental stage. It would be possible to firewall this 
into a separate application to protect the VM data, but the machine users 
would still have access to the PC side thru CPython. It would be possible to 
go a step farther and put Python in a PC of its own connected thru 
Infiniband. We've done this with Java, but the results are painful.

The goal at the moment is to see if I can make it appear that I have Python 
running more or less natively on the virtual machine. This means that Python 
will have direct access to user variables, files, and direct database access 
for the mainframe databases. Since the mainframe data format doesn't match 
that of the commmon Python objects, I'll either have to subclass the Python 
objects or make my own objects similar to the equivalent Python objects for 
things like numbers and strings. That is a project for tomorrow, not today. 
It seems straight-forward, just a lot of work.

> You want them to be able to share data, even at the level of a single
> variable.

Yes.

> That strongly suggests using the same CPython embed for all
> your users.

That was the conclusion I'd initially come to, yes.

> You can avoid name collisions simply by giving each user a
> module; one person's "spam" doesn't collide with another user's "spam"
> any more than math.log collides with logging.log. However, this is
> *not* protecting one user from another - it just protects against
> accidents. (I could easily reach into someone else's module by typing
> "fred.spam = 123".)

This particular mainframe architecture is odd, by today's machine standards. 
It is a stack machine. The stack is not a simple linear stack as far as 
addressing is concerned, but more of a tree structure. All user programs 
have stacks that are rooted at D0 in the operating system, at D1 in their 
own code file, and at higher levels in various nested program procedures. A 
new process can be created by forking at any level, and the new process 
shares all data with the original program from that level outward. It is 
possible for one stack to export procedure entry points that can be called 
by other stacks. Variables, arrays, files, etc, can be passed fron one stack 
(process) to another stack (process).

> So the question really becomes: How independent should the Pythons be?
> Sharing data is far easier if they're less isolated, but then it's
> harder to multithread.

The desirable goal is to make it look like Python is a native language 
running on this machine, but also giving access to existing Python libraries 
running on the PC that contains this virtual machine. Effectively this is 
extending the boundaries of the virtual machine to include processor chips 
of a different architecture within the scope of the VM. This has security 
implications, but at the moment they are (at least partially) understood and 
accepted.

> And above all, the security question.

See last sentence above.

Thanks!
        Loren