On Fri, Apr 08, 2016 at 03:37:45PM +0100, Paul Moore wrote: > On 8 April 2016 at 15:18, Jon Ribbens <jon+python-...@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. _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
