Re: [Python-Dev] Challenge: Please break this! (a.k.a restricted mode revisited)
On 8 April 2016 at 16:18, Jon Ribbens
wrote:
> I've made another attempt at Python sandboxing, which does something
> which I've not seen tried before - using the 'ast' module to do static
> analysis of the untrusted code before it's executed, to prevent most
> of the sneaky tricks that have been used to break out of past attempts
> at sandboxes.
>
> In short, I'm turning Python's usual "gentleman's agreement" that you
> should not access names and attributes that are indicated as private
> by starting with an underscore into a rigidly enforced rule: try and
> access anything starting with an underscore and your code will not be
> run.
>
> Anyway the code is at https://github.com/jribbens/unsafe
> It requires Python 3.4 or later (it could probably be made to work on
> Python 2.7 as well, but it would need some changes).
>
> 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?
>
If i'm not mistaken, this breaks out:
> exec('open("out", "w").write("a")', {})
because if the second argument of exec does not contain a __builtins__ key,
then a copy of the original builtins module is inserted:
https://docs.python.org/3/library/functions.html#exec
___
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
Re: [Python-Dev] file system path protocol PEP
On 11 May 2016 at 22:51, Ethan Furman wrote: > On 05/11/2016 01:44 PM, Serhiy Storchaka wrote: > > os.path >>> ''' >>> >>> The various path-manipulation functions of ``os.path`` [#os-path]_ >>> will be updated to accept path objects. For polymorphic functions that >>> accept both bytes and strings, they will be updated to simply use >>> code very much similar to >>> ``path.__fspath__() if hasattr(path, '__fspath__') else path``. This >>> will allow for their pre-existing type-checking code to continue to >>> function. >>> >> >> I afraid that this will hit a performance. Some os.path functions are >> used in tight loops, they are hard optimized, and adding support of path >> protocol can have visible negative effect. >> > > Do you have an example of os.path functions being used in a tight loop? > os.path.getmtime could be used in a tight loop, to sync directories with a lot of files for instance. % python3 -m timeit -s "import os.path; p = 'out'" "hasattr(p, '__fspath__'), os.path.getmtime(p)" 10 loops, best of 3: 2.67 usec per loop % python3 -m timeit -s "import os.path; p = 'out'" "isinstance(p, (str, bytes)), os.path.getmtime(p)" 10 loops, best of 3: 2.45 usec per loop % python3 -m timeit -s "import os.path; p = 'out'" "os.path.getmtime(p)" 10 loops, best of 3: 2.02 usec per loop a 25% markup is a lot imo. a isinstance check prior to the hasattr might be a way to mitigate this a bit (but it doesn't help much) Granted, this example could be optimised by calling os.stat directly, which is not in os.path, but still, worth considering ___ 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
[Python-Dev] Re: PEP 622: Structural Pattern Matching
On Fri, 26 Jun 2020 at 09:07, Greg Ewing wrote: > On 26/06/20 2:10 pm, Gregory P. Smith wrote: > > match get_shape() as shape: > >case start, end := Line@(shape): > > This looks just as inscrutable to me in its own way. > Absolutely, but that's kind of the point I think: no possible way to understand it for something else that what it means. Arthur ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/5AN52CT5BYARJHO3BL3OMXI4A27DHJCH/ Code of Conduct: http://python.org/psf/codeofconduct/
