Hi Stig, On Thu, Mar 21, 2002 at 10:00:48AM +0100, Stig S. Bakken wrote: > I just asked a friend of mine who is using Pair if he could dl() > modules. Pair give users their own extension_dir, but no access to > php.ini, and no way of reloading the server (which would still be > required for an auto-load extension dir). So for Pair users, dl() is > currently the _only_ way to load third-party extensions.
> The reason Pair do this, according to my friend, is that in case Apache > crashes, they will at last know what modules were loaded for all > processes, only the processes that run PHP scripts doing dl() will crash > because of bugs in the 3rd party extensions. > Following this train of thought, an auto-load extension folder would not > be a solution either, because it would still lead to the additional > vulnerability to Apache processes that Pair avoid this way. > I think we should bring in some people from hosting companies into this > discussion, to make sure we have all the facts right. Right now we are > assuming a bit too much. Saw this message in the archive, and figured I might as well throw in my two cents. My own background is that I'm a webmaster and sysadmin for a (PHP-friendly) regional ISP/hosting company in the US. I'm also currently involved in preparation of the PHP binaries that Debian ships, which means I get to hear about it any time those binaries don't work. I would be so bold as to guess that roughly 35-40% of the show-stopper bug reports I've seen relating to the Debian PHP packages involve problems with conflicting libraries. This percentage has gone down quite a bit in the past year, mostly due to the work of Petr Cech before me; but there are still problems that show up periodically as segfaults either at Apache load time or during script execution. And unfortunately, most of these segfaults are caused by conflicts between various libraries that are *dependencies* of PHP extenions, not by the PHP extensions themselves, which makes it hard to find a general solution to the problem; it takes someone standing by ready to play whack-a-bug every time these issues show up. Now, my employer has it relatively easy -- they have a webmaster who, ah, 'enjoys' playing with gdb, and these library conflicts are worked out long before they ever reach our production system. Others might not be so lucky as to be using Debian on their webservers. ;) Enter dl(), stage left. If you have five different websites on your server, each of which makes use of two different PHP extensions that are compiled as shared modules, I'm sorry to say that there's a not insignificant chance that you'll never get Apache to start without segfaulting if you list all of those extensions in your php.ini. But, if you enable each of those customers to use dl(), there's a pretty good chance (assuming sane library loading/unloading behavior on PHP's part) that all of the sites can happily coexist. It may not be pretty, but until there's a general solution to the sort of complex library dependency problems that are likely to arise on ELF platforms (Linux in particular), I believe it's necessary. Oh, and all the talk in this thread about security is a red herring. Really now, installing arbitrary modules into extension_dir just so you can dl() them? If the hosting environment's properly configured, the attacker's not going to be able to write to that directory; and by the time they get write access to that directory, there are lots of easier attacks that they can mount against the system -- like editing php.ini directly, or *replacing* an exiting .so that's already being referenced. Having a world-writable extension_dir filled with read-only files is such an edge-case in the land of bizarre configuration errors that it's certainly not worth preventing at the expense of those who have genuine uses for dl(). Cheers, Steve Langasek postmodern programmer
msg36144/pgp00000.pgp
Description: PGP signature
