On Mon, Jul 20, 2020 at 2:14 AM Robert
Hi, I’ve been lurking for a while. This is my first real post in a long time.
This is a proposal for a system-less python; that is, a version of python that does not have file or other inappropriate access to the os. The idea is to provide a python environment capable of safely running insecure scripts. The inspiration and obvious use case for this is an addition to or replacement for Javascript scripting in a web browser. Another use might be for scripting a spreadsheet, such as Excel.
I do not think this needs to be a separate version of Python. The disable feature could be controlled by a command line flag, which would also have other uses described below. For an embedded system, this could be compiled in somehow.
I don’t think the changes to the language would be all that great. The only built in change would be disabling the open function call, so there could be no local file access.
The next issue is the standard library, a lot of which would have to be disabled. Certainly the os and subprocess modules would not be allowed. On the other side, there should be no restrictions on, for example, collections or strings.
The biggest problem is third party imports. We can’t just disallow them. The whole point of a browser plug in would be to allow gui.
This has been proposed many MANY times. It never really works well, because Python is incredibly introspectable. Consider this:
1.0.__class__.__bases__[0].__subclasses__()
Behold, a probably-complete list of every class currently loaded. Do you want to try to guarantee that not one of them will let the user escape the jail? Or this: try: 1/0 except ZeroDivisionError as e: e.__traceback__.tb_frame.f_globals["__builtins__"].__import__("importlib") That'll import a module. To create a restricted Python, you either have to restrict it so much that it doesn't feel like a full language any more, or you constantly have to be on the lookout for leaks. Alternatively, do it all at an external level: for instance, a chroot jail, or process-based permissions. That's a lot more reliable, but it's much harder to sandbox just part of your app (eg the user-provided code). ChrisA