sean finney wrote:

>  On Tuesday 13 May 2008 09:03:08 pm Stanislav Malyshev wrote:
> 
> > I don't know - it depends how broad is the need for it and how other
> > developers perceive it.
>  
>  just to throw in my 0.02 $LC_MONETARY, it would be really useful to have 
>  something like this in debian and other php-packaging distributions out 
>  there.
>  
>  consider the scenario where a user installs via the package management system 
>  the php core plus extensions a, b, and c.  they later want to install 
>  extension d (which is not packaged) via pecl, and update/override extension 
>  c.
 > 
 >  ....
 > 
>  anyway, hope to see something like this down the line!

Thanks for your input Sean.

I have the change to ext\standard\dl.c working very nicely for PHP 5.2. 
I spent more time finally getting the building of PHP5TS.DLL under 
windows with the goal of reproducing an official release image (same 
exports, imports, built-in extensions, ect) so it would be a plug and 
play feature for anyone using PHP 5.2.  But I guess this will only by 
provided as a patch for PHP 5.2 since as I understand it, there would be 
  no more releases under PHP 5.2 (unless a critical/security bug was 
found).

I am now working on getting the new PHP 5.3 building process setup with 
its new pecl2 libraries, etc so once thats done, I'll patch dl.c for PHP 
5.3.

BTW, the technical outline semantics for this is:

   1) Secure dynamically modules (loaded via script)
      against filenames with paths.

   2) Allow explicit loading of persistent FQFN modules
      (but no relative path, no ".." in filename) or when
      the extension_dir is empty.

      Note: The problem here I don't see how you can create an
      empty extension_dir via the PHP.INI.  PHP seems to
      default implicitly to "C:\PHP5" string (literally) in
      the official builds. A blank, extension_dir="", does
      not work.

      If blank, it should do a WIN32 API call to

          GetModuleFileName(NULL,szPhpFileName, NULL)

      to get file location of the PHP EXE process, rather then use
      hard coded "C:\PHP5".

   3) Finally, parse the multiple paths, if any, attempt to
      load the parsed_path + filename.

The logic keeps with PHP 5.2 and the current PHP 5.3 change that allows 
for an explicit load if the filename contains slashes.  However, my 
change does not allow it if there are relative parts ("..") in the file 
name.  For (low) security reasons, relative paths should only be off an 
explicitly extension_dir="non_blank" definition as prepared by the local 
operator so there are no security surprises.

If fact, I could see a new option:

    extension_allow_relative_loads = No   <-- new default behavior

But it might be an overkill to add this.

-- 
Hector Santos, CTO
Santronics Software, Inc.


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php