From: codeslinger at compsalot dot com
Operating system: ALL
PHP version: 5.2.5
PHP Bug Type: Safe Mode/open_basedir
Bug description: fixing dl() has caused unintended consequences
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.
--
Edit bug report at http://bugs.php.net/?id=43737&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=43737&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=43737&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=43737&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=43737&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=43737&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=43737&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=43737&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=43737&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=43737&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=43737&r=support
Expected behavior: http://bugs.php.net/fix.php?id=43737&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=43737&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=43737&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=43737&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=43737&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=43737&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=43737&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=43737&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=43737&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=43737&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=43737&r=mysqlcfg
