On Sun, Aug 17, 2003 at 09:12:57AM -0700, Rasmus Lerdorf wrote: > On Sun, 17 Aug 2003, Steve Langasek wrote: > > 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
> Most of these seem to be symbol clash problems (Ok, I didn't read them > all) or problems vaguely attributed to Apache's double init phase on > startup. In general, yes. > Your conclusion that pushing towards dl() instead of figuring out what is > messing up the extension=foo.so style of loading libraries is misguided. I don't think it's misguided to want to mitigate the impact of library bugs on PHP. Some of these bugs have taken months at a time to iron out, because they require the cooperation of upstream library developers to fix in the case of symbol collisions. (The Kerberos symbol collision bug -- still unresolved -- requires the cooperation of two upstream library maintainers and four Debian package maintainers to fix.) Our users are better served by not being exposed to such bugs in the first place. > dl() is slow because the library is loaded and unloaded on every single > request. dl() is clunky because it isn't, and I don't see how it could > ever be, threadsafe. And finally it has some nasty security implications. > I understand you want to address these with safemode changes, but many > servers don't run safemode (because it is not actually very safe and in > general it is crap) and the damage a user can do is somewhat limited. By > forcing them to allow dl() users can now load arbitrary C code directly > into the web server process and really really mess stuff up. Well, I'm not convinced that it couldn't be made threadsafe, at least on the platforms I'm concerned with. I'm told that glibc 2.3's dlopen()/dlclose() is supposed to have thread-intelligent reference counting. And I certainly agree that there are some tradeoffs to consider when enabling dl() support on a server; however, if safe_mode is not enabled, there are lots of other ways you can do nasty things to the server using arbitrary C code -- system(), for example. (Given that a well-constructed [or poorly constructed?] system() can far outlive a single HTTP request, I'd be more concerned about the potential for damage there.) As for performance: I'm sure many of our users would gladly sacrifice a bit of performance in exchange for something that works when they ask it to. A fully functional dl(), together with defensive coding on the part of PHP script authors, would give users the flexibility they need when things don't work right -- in /either/ direction. > Nobody here is saying that we don't want to support folks building binary > distributions of PHP. We are just saying that your chosen path is a bad > idea and that we need to address the real problem instead. > Architecturally it makes absolutely no sense to load and unload libraries > on a per-request basis. This has to happen at server startup. Addressing the "real problem" means chasing down each bug individually in a different library. I've spent a year doing that, and I no longer agree that it's the right way to proceed. The imap/ssl bugs have been a game of hide-and-seek from the start, and the most recent one -- http://bugs.debian.org/205553 -- doesn't even appear to be a problem with a mislinked library. Rather, there seems to be something broken deep in the source code of either libssl/libcrypto or libc-client. Since those are the top two hairiest libraries I've ever worked with, I'm not particularly enthusiastic about trying to chase down the one line of hair that happens to host a bug; but if you want to tackle that, I would certainly be grateful to see the bug fixed. > One thing we should probably do is not dlclose() any shared extensions on > shutdown. I am not sure if your list of bugs included any reports of > crashes on shutdown, but if you ever come across one of those it is likely > that removing the dlclose() will fix it. I don't recall ever seeing such a bug report. At least in the case of library symbol conflicts, leaving the shared extension open after the end of a request would have exactly the opposite effect, though. -- Steve Langasek postmodern programmer
pgp00000.pgp
Description: PGP signature
