Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:85856
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.217.182 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAMUwpuTZK=zqHcWG21DA5fUSODuq6njyx9+RUtQR0gQu02a5AQ@mail.gmail.com>
References: <CAMUwpuTZK=zqHcWG21DA5fUSODuq6njyx9+RUtQR0gQu02a5AQ@mail.gmail.com>
Date: Fri, 17 Apr 2015 18:43:49 +0200
Message-ID: <CAH-PCH6Q-=dxPGPKnFhBsYVqVetYJPyOauUcCZFm6NRaoZp27A@mail.gmail.com>
To: Julien Pauli <jpauli@php.net>
Cc: Andrew Faulds <ajf@ajf.me>, PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11c33c0ae4fb830513ee4849
Subject: Re: [PHP-DEV] Closure::call() to access private data, really ?
From: tyra3l@gmail.com (Ferenc Kovacs)

--001a11c33c0ae4fb830513ee4849
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Fri, Apr 17, 2015 at 6:11 PM, Julien Pauli <jpauli@php.net> wrote:

> Just a simple use case showing how dangerous that is :
>
> <?php
> $p =3D function($p) { $this->$p =3D new Stdclass; };
> $p->call($e =3D 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 t=
o
> access private data.
>
> Private is private.
>
> For internal classes, this is even worse, and could lead to crash (look a=
t
> 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 >=3D5.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.

--=20
Ferenc Kov=C3=A1cs
@Tyr43l - http://tyrael.hu

--001a11c33c0ae4fb830513ee4849--