Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:50202
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain lerdorf.com from 209.85.160.42 cause and error)
Message-ID: <4CE10E8E.3070901@lerdorf.com>
Date: Mon, 15 Nov 2010 02:42:22 -0800
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.12) Gecko/20101027 Lightning/1.0b2 Thunderbird/3.1.6
MIME-Version: 1.0
To: Andi Gutmans <andi@zend.com>
CC: internals <internals@lists.php.net>
References: <4CE03E41.9030805@lerdorf.com> <8757232E56758B42B2EE4F9D2CA019C9086B69@US-EX2.zend.net>
In-Reply-To: <8757232E56758B42B2EE4F9D2CA019C9086B69@US-EX2.zend.net>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Adding path_len to all stream functions in trunk
From: rasmus@lerdorf.com (Rasmus Lerdorf)

Ok, I went through all the 5.3 code.  This should fix the null poisoning
problems in 5.3 without breaking binary compatibility:

http://progphp.com/nullpatch.txt

There are quite a few places where we can't solve it centrally, so
perhaps we need to take the same approach in trunk.

This should take care of every issue mentioned here:

http://www.madirish.net/?article=436

along with a number of bug reports.

I think the only outstanding issue with the patch is whether to show an
error message when we hit a null in a filesystem path string.  With the
Zend part of the patch, right now the error is slightly misleading for
code like this:

$file = "foo.php\0";
include $file . ".png";

This will output:

PHP Warning:  include(): Failed opening 'foo.php' for inclusion
(include_path='.:') in foo on line 3

Without this patch, this code will of course simply include the foo.php
file and ignore the .png extension.

-Rasmus

On 11/14/10 9:35 PM, Andi Gutmans wrote:
> Hi Rasmus,
> 
> Hope I understood the problem correctly. If not, this answer won't make sense :)
> I do not see a major problem in passing path_len but wonder how much it'd actually solve as we end up calling OS APIs that do not accept path_len, no? I assume we don't want to start searching all these strings for invalid chars before we pass them to the OS.
> 
> Andi
> 
>> -----Original Message-----
>> From: Rasmus Lerdorf [mailto:rasmus@lerdorf.com]
>> Sent: Sunday, November 14, 2010 11:54 AM
>> To: internals
>> Subject: [PHP-DEV] Adding path_len to all stream functions in trunk
>>
>> I think we need to pass along the string length to all the stream functions to
>> maintain binary string safety through this code.  This would fix annoying
>> problems like http://bugs.php.net/39863 and a bunch of similar issues.
>> Obviously not something we can do in 5.3 without breaking binary compatibility
>> though.  Although we might be able to do something if we assume only chars
>> valid in the current charset is valid in file paths.
>>
>> Anybody have any other thoughts on this one?
>>
>> -Rasmus
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit:
>> http://www.php.net/unsub.php
>