RetroSearch Browse

Fri Apr 8 10:55:36 EDT 2016 · https://mail.python.org/pipermail/python-dev/2016-April/143788.html

On Fri, Apr 08, 2016 at 03:37:45PM +0100, Paul Moore wrote:
> On 8 April 2016 at 15:18, Jon Ribbens <jon+python-dev at unequivocal.co.uk> wrote:
> > I would be very interested to see if anyone can manage to break it.
> > Bugs which are trivially fixable are of course welcomed, but the real
> > question is: is this approach basically sound, or is it fundamentally
> > unworkable?
> 
> What are the limitations? It seems to even block "import" which seems
> over-zealous (no import math?)

The restrictions are:

  Of the builtins, __import__, compile, globals, input, locals,
  memoryview, open, print, type and vars are unavailable (and
  some of the exceptions, but mostly because they're irrelevant).

  You cannot access any name or attribute which starts with "_",
  or is called "gi_frame" or "gi_code".

  You cannot use the "with" statement (although it's possible it might
  be safe for me to add that back in if I also disallow access to
  attributes called "tb_frame").

Importing modules is fundamentally unsafe because the untrusted code
might alter the module, and the altered version would then be used by
the containing application. My code has a "_copy_module" function
which copies (some of) the contents of modules, so some sort of
import functionality of a white-list of modules could be added using
this, but there's no point in me going through working out which
modules are safe to white-list until I'm vaguely confident that my
approach isn't fundamentally broken in the first place.

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2016-April/143788.html below:

[Python-Dev] Challenge: Please break this! (a.k.a restricted mode revisited)