Re: Extension_Dir: Proposal to offer multi-directory DLL loading

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.