Python Security (split from MOUL forum)

[Christian Walther]

I'm taking this over here since it might cut into the territory Cyan would prefer to keep outside of their own forum.

In the Open Source Security Concerns thread on the MOUL forum,

Uru's python does not include many of the standard Python modules (including the socket modules listed above). As well, every Python script runs in its own instance of the runtime and cannot interact with files outside of the game directory.

Is this something that has changed in MOUL? I just tried it in CC and I'm perfectly able to read and write files outside of the game directory.

Also, what exactly do you mean by "its own instance of the runtime"? Its own Python interpreter instance? (Does Python even allow multiple interpreter instances in the same process? From my own experience with embedding Python, it doesn't look like it, but I'd have to study the documentation again.)

Edit: Come to think of it, it can't have changed in MOUL, I've done it there too - using the Jalak /loadcolumns and /savecolumns commands.

[Zrax]

I think he's referring to python source files actually. However, that's not strictly true either, since you can use something like execfile() to get source files from outside the pak... However, that call must eventually originate from a source file that *is* in the pak, as you cannot have the game directly load a file that isn't in a PAK (to the best of my knowledge -- I haven't tested this though)

[Christian Walther]

You can also import naked Python files from the python, python/system, and python/plasma folders, and from anywhere if you modify sys.path. It doesn't seem to be possible to override pakked modules that way though, they seem to be loaded all at once at launch, bypassing the normal module search mechanism, so you still need to start from inside the paks.

However, access to outside Python code is largely irrelevant for the discussion in the original thread, which is about the threat posed by malicious Ages. They already have their code in the paks and don't need to inject it from elsewhere. (It could be relevant insofar as the mechanism could be used to load C modules that can do things that pure Python code can't. To take the popular example, I could probably speculate on the user having a full Python installation in some standard place, try to import the socket module from there, and open all the backdoors I want.)