On Mon, Jul 20, 2020 at 2:14 AM Robert <rk546...@gmail.com> wrote:
>
>
> 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
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/2Z4RBR3DMIUHO3PGDVQEWIU6EEUJOMBV/
Code of Conduct: http://python.org/psf/codeofconduct/
