Re: Adding path_len to all stream functions in trunk

hi, Patch applied in 5.3. I will do in trunk next week. Cheers, On Mon, Nov 15, 2010 at 11:42 AM, Rasmus Lerdorf <rasmus@lerdorf.com> wrote: > 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 >> > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org