Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:37664 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 63846 invoked from network); 15 May 2008 07:50:56 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 15 May 2008 07:50:56 -0000 Authentication-Results: pb1.pair.com header.from=hsantos@isdg.net; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=hsantos@isdg.net; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain isdg.net designates 208.247.131.9 as permitted sender) X-PHP-List-Original-Sender: hsantos@isdg.net X-Host-Fingerprint: 208.247.131.9 ntbbs.winserver.com Windows NT 4.0 (older) Received: from [208.247.131.9] ([208.247.131.9:4759] helo=winserver.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 80/21-56615-E5BEB284 for ; Thu, 15 May 2008 03:50:55 -0400 Received: from mail.winserver.com ([208.247.131.9]) by winserver.com (Wildcat! SMTP Router v6.3.452.5) for internals@lists.php.net; Thu, 15 May 2008 03:49:43 -0400 Received: from hdev1 ([72.144.71.18]) by winserver.com (Wildcat! SMTP v6.3.452.5) with ESMTP id 1279127953; Thu, 15 May 2008 03:49:41 -0400 Message-ID: <482BEB21.8030200@isdg.net> Date: Thu, 15 May 2008 03:49:53 -0400 Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: sean finney CC: internals@lists.php.net, Stanislav Malyshev References: <4824219D.3070806@isdg.net> <4828FD20.9020602@isdg.net> <4829E5EC.1020706@zend.com> <200805150900.57485.seanius@seanius.net> In-Reply-To: <200805150900.57485.seanius@seanius.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] Extension_Dir: Proposal to offer multi-directory DLL loading From: hsantos@isdg.net (Hector Santos) 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.