Re: Problem with ext/libxml RINIT/RSHUTDOWN

Sounds like a nasty situation. I don't think it's possible to sanely restore the handlers at rshutdown in a threaded build without screwing up the other threads that are currently executing. My suggestion is to not restore the handlers for threaded builds, and if there is a library sharing/abuse issue, then treat it as an installation/configuration problem for the person deploying it (eg: don't do that!). There's not much you can do about that without rewriting libxml2 to not use globals for the callbacks. :-/ --Wez. On 3/17/06, Rob Richards <rrichards@ctindustries.net> wrote: > Dmitry Stogov wrote: > > Hi Wez, > > > > I found a bad code in ext/libxml. > > > > On each request startup/shutdown it changing some libxml callbacks. > > At first this slowdown each request, at second multi-threaded PHP may fail, > > because different threads may set/clean the same callbacks in the same time. > > > > May be it is possible to setup these callbacks forever in MINIT/MSHUTDOWN, > > set some flag (somthing like LIBXML(in_request)) in RINIT/RSHUTDOWN, and > > check it in callbacks. > > > Which ones in particular? > Each of the callbacks being utilized are thread safe. > The reason why they need to be set per request is in order to play nice > with any other modules that might be loaded and use libxml2. > > for example: prior to how the current callbacks are implemented it was > possible to blow away PHP stream usage by any of the xml extensions > using mod_perl and its xsl module (could do this whether or not PHP was > running threaded). > There are also many other ways to screw with the libxml2 globals and > effect PHP extensions based on libxml2 as well using other modules so > the only way to protect them is on each request. In short putting them > into the MINIT/MSHUTDOWN will open security holes. > > Rob >