On Sun, Aug 17, 2003 at 11:52:13AM +0200, Derick Rethans wrote: > On Sat, 16 Aug 2003, Steve Langasek wrote:
> > The attached patch changes dl() so that, instead of outright refusing to > > run under safe mode, it performs additional security checks on the value > > of extension_dir and accepts a filename-only argument (no directories) > > from the caller. In addition, if the provided argument doesn't return a > > handle, dl will append the value of PHP_SHLIB_SUFFIX to the filename and > > try again. > > Rationale: Most Linux distributions that include PHP ship the majority > > of extensions as shared objects, to make it easier for the user to get > > just those features they need. In addition, there are many extensions > > not provided by Linux distributors that a user may wish to add locally. > > Unfortunately, current PHP programmer culture leads to all extensions > > being loaded via php.ini, which -- contrary to some claims made in the > > past on this list -- often causes instability when used with apache 1.3. > Loading them through dl() gives much more instability. I don't see where > you got this claim from, I never saw a bugreport about this. http://bugs.debian.org/131080 http://bugs.debian.org/131724 http://bugs.debian.org/165699 http://bugs.debian.org/165718 http://bugs.debian.org/165719 http://bugs.debian.org/166414 http://bugs.debian.org/188014 http://bugs.debian.org/188025 http://bugs.debian.org/188058 http://bugs.debian.org/189202 http://bugs.debian.org/189653 http://bugs.debian.org/200255 http://bugs.debian.org/205592 This claim comes from over a year of fighting with linker/library bugs that impact *nothing else* in Debian besides PHP. They don't get filed against bugs.php.net because they're almost always library bugs, not PHP bugs; indeed, the above list is absolutely *not* definitive, because most such bugs get reassigned to library packages for fixing, and I lose track of them. But even though the libraries have bugs, these bugs are *only* exposed by PHP. No other scripting language has problems like these, not even other languages that are loaded as Apache DSOs (mod_python, mod_perl); and in every case, these bugs could be resolved by removing an 'extension=' line from php.ini and using dl() instead. Last March, I offered some comments on this mailing list in response to dl() discussion suggesting that 35-40% of all showstopper bugs in Debian's PHP packages could be resolved by use of dl(), and that the percentage was falling. Based on the past year, I find that I need to revise that estimate to 70%. Now, the other possibility is that taking libc-client out back and shooting it would also resolve all of the PHP-related crashes, since php4-imap is at the core of most of them. Unfortunately, php4-imap is also one of the most widely used extensions, and porting it to a suitable alternative library is not an endeavor to be undertaken lightly. > > Simply put, the current state of libraries on Linux isn't good enough to > > cope with all possible libraries being loaded into a single apache > > process at once; and SSL-using extensions seem to have problems of their > > very own when it comes to Apache's load-unload-load-rinse-spindry > > handling of DSOs at start time. Supporting a reasonable dl() function > > under safe mode is the first step toward being able to wean users off of > > this fragile configuration. > I don't agree, dl() is kinda deprecated anyway. It's buggy as hell and > it causes quite a lot of problems with intra-extension dependencies. *Not* using dl() causes a lot of problems with inter-extension dependency conflicts. Under the circumstances, I believe it's important to support both modes of operation equally, to the extent possible. > If you want something solid, you compile in all extensions. This has > nothing to do with safe-mode really. So you don't intend to support distributors of PHP binaries for Unix? Monolithic binaries are not an option for us: we're actively trying to *reduce* the number of dependencies of any one PHP package in Debian right now in the interest of release management, and there are some extensions we wouldn't be able to compile in if we wanted to, that users may still want to load later. Loading all of the shared extensions at startup causes crashes. That seems to leave dl() as the only option, but you apparently won't accept a patch to even make dl() work for all Apache 1.3 users. I understand from the source that there are concerns about the viability of dl() under threaded webservers; and when the time comes, I'm prepared to work on sorting out such stability problems if need be (it's also possible that Apache2's startup process is nicer to libraries than Apache 1.3's is). But my users are *not* using ZTS today; rather, they *are* seeing crashes that could be resolved through the use of dl(). -- Steve Langasek postmodern programmer
pgp00000.pgp
Description: PGP signature
