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
--
https://mail.python.org/mailman/listinfo/python-list
