On Fri, Apr 17, 2015 at 6:11 PM, Julien Pauli <jpa...@php.net> wrote:
> Just a simple use case showing how dangerous that is :
>
> <?php
> $p = function($p) { $this->$p = new Stdclass; };
> $p->call($e = new Exception, 'trace');
> throw $e;
>
>
> That nearly crashes PHP7.
> http://3v4l.org/fJj22
>
> (The same trick using Reflection with PHP5 crashes the engine, this is a
> known bug that we chose not to fix).
>
>
> I am absolutely not confident at all having Closure::call() beeing able to
> access private data.
>
> Private is private.
>
> For internal classes, this is even worse, and could lead to crash (look at
> the example about Exception).
> Changing a variable that is private, is absolutely NOT expected from the
> class designer.
>
> For User classes, this could lead to information leaks or bad behaviors,
> and for internal classes this is even worse and could easilly segfault or
> with a little bit of more magic and brain sauce, lead to memory
> disclosures.
>
> I would like we re-open the debate about accessign private data with
> external code (closure), especially in a write context.
>
>
> Julien.P
>
For the record this isn't exclusive to Closure::call, afaik the same thing
is possible with Closure::bind() since 5.4
http://3v4l.org/hlFS4
And there are/were a decent amount of discussion (and AFAIR even hydrate
libraries using this trick) about this, for example:
http://ocramius.github.io/blog/accessing-private-php-class-members-without-reflection/
So while I think that for 7.0 we could remove this behavior, the cat is
already out of the bag, as you can see from my paste you can use that code
to cause segfaults for php >=5.4.0, so I think it would be better to fix
the internal classes to properly handle/validate their properties instead
of blindly trusting their types.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
