[Python-ideas] make __closure__ writable
yselivanov.ml at gmail.com
Fri Mar 23 16:59:43 CET 2012
On 2012-03-23, at 12:08 AM, Nick Coghlan wrote:
> On Fri, Mar 23, 2012 at 1:44 PM, Eric Snow <ericsnowcurrently at gmail.com> wrote:
>> Will we see a "significantly" higher number of bugs about segfaults
>> where we have to respond with "don't do that"? Probably not. But
>> should any solution here guard (at some expense) against such mistakes
>> that currently are much more difficult to make? Nick already alluded
>> to double-checking the code somewhat to that effect.
> Yes, while I'm in favour of the writable closure attribute idea in
> principle, the details of how we access the closure array are the kind
> of thing I'm worried about when I say I need to check the source code
> before commenting on the implementation details. Setting
> "f.__closure__ = " is a lot easier than crafting the necessary
> bytecode to cause problems with the current setup, so "Can the new
> behaviour be abused to segfault CPython with pure Python code?" is
> exactly the right question to be asking.
Well, it does look easier, but on the other hand you can substitute the
__code__ object with just two more lines, and it may be as fatal as
writing wrong __closure__.
> With Victor's recent work to close some longstanding segfault
> vulnerabilities, I really don't want us to be adding anything that
> goes in the other direction. However, I won't be doing that
> investigation myself until my broadband provider finally finishes
> setting up the connection at my new place, so if anyone wants to cast
> an appropriately paranoid eye over Yury's patch in the meantime,
> please go ahead :)
I get the point of segfault vulnerabilities and don't want to introduce
any new ways either.
Will adding two checks:
*) in closure_setter check that all items in the tuple are cells AND that
the length of new __closure__ greater or equal than __code__ freevars;
*) in code_setter check that __code__ freevars are less or equal to the
This way you won't be able to segfault python, but will have a freedom to
manipulate the __closure__ by introducing more vars to it.
More information about the Python-ideas