Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:85857
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain ajf.me designates 198.187.29.252 as permitted sender)
References: <CAMUwpuTZK=zqHcWG21DA5fUSODuq6njyx9+RUtQR0gQu02a5AQ@mail.gmail.com> <CAH-PCH6Q-=dxPGPKnFhBsYVqVetYJPyOauUcCZFm6NRaoZp27A@mail.gmail.com>
Mime-Version: 1.0 (1.0)
In-Reply-To: <CAH-PCH6Q-=dxPGPKnFhBsYVqVetYJPyOauUcCZFm6NRaoZp27A@mail.gmail.com>
Content-Type: multipart/alternative;
	boundary=Apple-Mail-BAF714BC-9FD4-4A78-8D84-36D8666B3CF6
Content-Transfer-Encoding: 7bit
Message-ID: <1970A97A-1AFB-4A31-BA1B-6873979A9A41@ajf.me>
Cc: Julien Pauli <jpauli@php.net>, PHP Internals <internals@lists.php.net>
Date: Fri, 17 Apr 2015 18:11:40 +0100
To: Ferenc Kovacs <tyra3l@gmail.com>
Subject: Re: [PHP-DEV] Closure::call() to access private data, really ?
From: ajf@ajf.me (Andrea Faulds)

--Apple-Mail-BAF714BC-9FD4-4A78-8D84-36D8666B3CF6
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable

Hi,

I'm no longer subscribed to internals so I don't know if this email will sho=
w up there. If not, feel free to forward it.

> On 17 Apr 2015, at 17:43, Ferenc Kovacs <tyra3l@gmail.com> wrote:
>=20
>=20
>=20
>> 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 :
>>=20
>> <?php
>> $p =3D function($p) { $this->$p =3D new Stdclass; };
>> $p->call($e =3D new Exception, 'trace');
>> throw $e;
>>=20
>>=20
>> That nearly crashes PHP7.
>> http://3v4l.org/fJj22
>>=20
>> (The same trick using Reflection with PHP5 crashes the engine, this is a
>> known bug that we chose not to fix).
>>=20
>>=20
>> I am absolutely not confident at all having Closure::call() beeing able t=
o
>> access private data.
>>=20
>> Private is private.
>>=20
>> 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.
>>=20
>> 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 disclosur=
es.
>>=20
>> I would like we re-open the debate about accessign private data with
>> external code (closure), especially in a write context.
>>=20
>>=20
>> Julien.P
>=20
> 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 l=
ibraries 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 al=
ready out of the bag, as you can see from my paste you can use that code to c=
ause segfaults for php >=3D5.4.0, so I think it would be better to fix the i=
nternal classes to properly handle/validate their properties instead of blin=
dly trusting their types.

Right, what Closure::call() does isn't particularly new. I'm not sure if it'=
s a good thing that you can arbitrarily re-scope closures, but that's how it=
 is.=20

Also, if information leaks are a worry, we've had things like ob_start() and=
 var_dump(), and (array) for a while now.

A further thought: type hints for class properties would be helpful here.

Thanks.

--
Andrea Faulds
http://ajf.me/=

--Apple-Mail-BAF714BC-9FD4-4A78-8D84-36D8666B3CF6--