Re: [Python-Dev] Some news from my sandbox project
Le dimanche 19 septembre 2010 01:05:45, Greg Ewing a écrit : > I don't follow. Trusted functions such as proxy() shouldn't > be sharing a __builtins__ dict with sandboxed code. > (...) > So give each program its own copy of __builtins__. By "program" you mean a "process"? proxy() and untrusted functions are executed in the same process and the same interpreter. Untrusted code calls (indrectly) proxy(): should I create a new copy of __builtins__ for each frame? I don't know how to do that in Python (without modify the Python interpreter) and I suppose that it will make Python slower. The frame mechanism is already slow (create a new frame to call a Python function is much slower than calling a function in C). pysandbox creates a new separated namespace for untrusted functions, but __builtins__ "namespace" (dict) is shared between Python and pysandbox namespaces. -- Victor Stinner http://www.haypocalc.com/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Some news from my sandbox project
On Sun, 19 Sep 2010 12:19:44 +0200
Victor Stinner wrote:
> Le dimanche 19 septembre 2010 01:05:45, Greg Ewing a écrit :
> > I don't follow. Trusted functions such as proxy() shouldn't
> > be sharing a __builtins__ dict with sandboxed code.
> > (...)
> > So give each program its own copy of __builtins__.
>
> By "program" you mean a "process"? proxy() and untrusted functions are
> executed in the same process and the same interpreter. Untrusted code calls
> (indrectly) proxy(): should I create a new copy of __builtins__ for each
> frame? I don't know how to do that in Python (without modify the Python
> interpreter) and I suppose that it will make Python slower.
>>> def f(): return oct
...
>>> f()
>>> import types
>>> m = types.ModuleType("my builtins")
>>> m.__dict__.update(__builtins__.__dict__)
>>> m.oct = 3
>>> f.__globals__['__builtins__'] = m
>>> f()
3
Regards
Antoine.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Rework nntplib?
For the record, the code is pretty much done now: http://bugs.python.org/issue9360 Regards Antoine. On Tue, 14 Sep 2010 12:17:44 +0200 Antoine Pitrou wrote: > > Hello, > > Like the email package, nntplib in py3k is broken (because of > various bytes/str mismatches; I suppose the lack of a test suite didn't > help when porting). > > I would like to take the opportunity to improve the API a bit; no heavy > re-architecting, but simply a bunch of changes to make it higher-level. > Is it acceptable? > > (and, yes, I would add a test suite) > > Regards > > Antoine. > > ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Rework nntplib?
On Mon, Sep 20, 2010 at 3:27 AM, Antoine Pitrou wrote: > > For the record, the code is pretty much done now: > http://bugs.python.org/issue9360 Generally looks pretty reasonable. As I noted on the issue, my one concern is that the current API seems to rely on the programmer remembering which methods return strings and which return bytes without any consistent mnemonic as to which is which. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Rework nntplib?
On Mon, 20 Sep 2010 06:55:50 +1000, Nick Coghlan wrote: > On Mon, Sep 20, 2010 at 3:27 AM, Antoine Pitrou wrote: > > > > For the record, the code is pretty much done now: > > http://bugs.python.org/issue9360 > > Generally looks pretty reasonable. As I noted on the issue, my one > concern is that the current API seems to rely on the programmer > remembering which methods return strings and which return bytes > without any consistent mnemonic as to which is which. The mnemonic is: *raw message data* is bytes, everything else is unicode. That is, the *content* of head, body, article, post, and ihave commands is bytes, otherwise you are dealing with strings. I think it is a very clear and obvious distinction, myself. --David ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Some news from my sandbox project
Victor Stinner wrote: By "program" you mean a "process"? No, I mean whatever *you* meant by "program" when you said that different programs could otherwise interfere with each other. If you have conceptually separate programs running in the same interpreter that need to be isolated, each one should run in its own sandbox with its own __builtins__ dict. > should I create a new copy of __builtins__ for each frame? No, not for each frame, just for each computation that needs to be isolated. -- Greg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Supporting raw bytes data in urllib.parse.* (was Re: Polymorphic best practices)
On Sep 18, 2010, at 10:18 PM, Steve Holden wrote: >> I could probably be persuaded to merge the APIs, but the email6 >> precedent suggests to me that separating the APIs better reflects the >> mental model we're trying to encourage in programmers manipulating >> text (i.e. the difference between the raw octet sequence and the text >> character sequence/parsed data). >> > That sounds pretty sane and coherent to me. While I don't like the email6 precedent as such (that there would be different parsed objects, based on whether you started parsing with bytes or with strings), the idea that when you are working directly with bytes or text, you should have to know which one you have, is a good one. +1 for keeping the APIs separate with 'urlsplitb' etc.___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
