Content-Type: text/plain; cht=us-ascii
On Sun, Aug 17, 2003 at 09:12:57AM -0700, Rasmus Lerdorf wrote:> On Sun, 17 Aug 2003, Steve Langasek wrote:> > [url]http://bugs.debian.org/131080[/url]
> > [url]http://bugs.debian.org/131724[/url]
> > [url]http://bugs.debian.org/165699[/url]
> > [url]http://bugs.debian.org/165718[/url]
> > [url]http://bugs.debian.org/165719[/url]
> > [url]http://bugs.debian.org/166414[/url]
> > [url]http://bugs.debian.org/188014[/url]
> > [url]http://bugs.debian.org/188025[/url]
> > [url]http://bugs.debian.org/188058[/url]
> > [url]http://bugs.debian.org/189202[/url]
> > [url]http://bugs.debian.org/189653[/url]
> > [url]http://bugs.debian.org/200255[/url]
> > [url]http://bugs.debian.org/205592[/url]In general, yes.> 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
I don't think it's misguided to want to mitigate the impact of library> Your conclusion that pushing towards dl() instead of figuring out what is
> messing up the extension=3Dfoo.so style of loading libraries is misguided.
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.
Well, I'm not convinced that it couldn't be made threadsafe, at least on> 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.
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
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.
Addressing the "real problem" means chasing down each bug individually> 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.
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 --
[url]http://bugs.debian.org/205553[/url] -- 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.
I don't recall ever seeing such a bug report. At least in the case of> 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.
library symbol conflicts, leaving the shared extension open after the
end of a request would have exactly the opposite effect, though.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
-----END PGP SIGNATURE-----