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
