php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #43737 fixing dl() has caused unintended consequences
Submitted: 2008-01-03 14:26 UTC Modified: 2008-01-28 23:48 UTC
From: codeslinger at compsalot dot com Assigned:
Status: Not a bug Package: Safe Mode/open_basedir
PHP Version: 5.2.5 OS: ALL
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: codeslinger at compsalot dot com
New email:
PHP Version: OS:

 

 [2008-01-03 14:26 UTC] codeslinger at compsalot dot com
Description:
------------
There is a joke which says 
 
  a bug which has a useful side affect is a *feature* 
 
 
This is a hang-over from the bad old days of beta quality software releases.  But for the first time in my programming career I have encountered a real life scenario in which that saying is literally true.

The alleged "dl() path bug", which has now been ~fixed~, has broken my (widely deployed) program...  or at least it will break if and when we try to roll out an upgrade to the latest php.

I have been using this ~feature~ since the early days of php 4.

Being able to specify a subdirectory of the Extensions folder is a very useful feature.  

I would ask that you please consider just how many .dll/.so modules that there actually are.  I think it is somewhere around 150 files (many with obtuse names) and growing, and those are just for the official releases.  Add to this the many 3rd party releases from other sources, and further consider that quite a few of these modules have negative interactions with each other.  Perhaps you can then appreciate what a huge management problem this has become.  


We are converging upon a state of chaos, not unlike the "DLL Hell" of Windows.


I want/need very much to be able to segregate the dlls.  I especially need to be able to keep the 3rd party dlls clearly separate from the official release dlls.

The extension load code was already able to do this, it was designed such that you can not specify any arbitrary directory, the only paths that it would accept were for subdirectories of the defined extension directory.  I believe that this already existing constraint was sufficient to ensure the security of the modules.

But now with the recent ~bug~ fix all extensions must reside in the same folder.  I know that this was done with the intention that it would make things more secure.  But I respectfully submit for your consideration, that not being able to segregate the extensions actually makes things less secure.  

Suppose for instance that I have an xyz dll and I only want one php program to be able to access it.  With separate directories I can easily enforce per user access permissions.  With everything in the same directory it would be much harder to ensure that access rights are consistently maintained.

Also consider the problem of file name collisions, there is no central clearing house for the registration of module names.  With many independent developers all creating extensions, file name collisions are inevitable.  And this will lead to hard to fix/detect breakage in the future when a newly added official release dll clobbers an already existing 3rd party dll of the same name.

Or consider the problem were you have two versions of a dll which has incompatible changes.  And you have a mixture of php programs some of which have been updated to use the new version and some which still require the old version.  Yes you could arbitrarily change the name of the dll, but that introduces long term maintenance headaches if you choose a different name then the originating source. -- true, it should not happen, the originator should have assigned a new name, but we all know that it often does not work that way in the real world.  By being able to use separate subdirectories for the different versions of the dll this becomes a non-problem.

So I am asking that you please unfix the bug fix and allow subdirectories to exist inside of the extension folder.  No new code is needed for this, it already used to work.  The documentation would need to be updated.

From a security stand-point, I believe that you could achieve your goal by simply disallowing links, and reviewing that indeed it is not possible to trick your way to a higher directory level.

I suspect the fundamental conflict here is that php is now performing in 3 different roles and the security requirements for each role are different.

As a cli, php has become a viable replacment for perl.  I now write php programs as the system glue, for all the things that were traditionally done by perl.  In cli mode while performing system maintenance tasks, these fully trusted php programs must be unencumbered or else they will be unable to perform the needed functions.

On the other hand, in it's role as mod_php it needs very tight constraints, especially when running untrusted code.  and in order to function, cgi_php is a little bit less restricted than mod_php.

But in all of those security modes, it would be useful to be able to segregate the extensions into multiple directories.

Thank you


Reproduce code:
---------------
//create a directory under the extensions directory 
//and put foo.dll in it

dl('subfolder/foo.dll');

//or even


dl('/subfolder/foo.dll');




Expected result:
----------------
foo.dll which exists in a subfolder under the extensions folder is loaded.



Actual result:
--------------
As of 5.2.5  you get a 'not found' error message as a result of a bug/security fix.

In previous versions of php, the module would be loaded.


Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2008-01-28 23:48 UTC] tony2001@php.net
It makes no sense to "unfix" something.
If you want to discuss it or have a proposal, please use mailing lists, not a bug tracker.
Thank you.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Thu Mar 28 17:01:29 2024 UTC