> At 10:43 AM 3/12/2002, Shane Caraveo wrote: > > > The stability issue is fairly obvious (you're much more likely to screw up > > > in a multithreaded environment if you load/unload libraries like hell, than > > > you are if you load them once, process-wide; this affects both code in PHP > > > and code in the libraries themselves). > > > >That has nothing to do with dynamically loading modules at runtime. > > It has lots to do with that. > > >First, the modules should not be unloaded until php is unloaded. > > Then you're not talking about dl(), because dl()'d modules get unloaded at > the end of the request.
I am talking about dl. 'should' being the keyword. I see no reason at all that dl should unload the module after the request, and the fact that it does seems to be the primary reason there are problems and (probably) its getting depricated. > We can, relatively easily, add an administrative way of loading modules, > server-wide and without being able to unload them. This will not, however, > be anything that's remotely equivalent to dl(), and does not address your > (IMHO unexplained) requirement to 'load different modules for different > parts of the site'. It absolutely does, and being able to do it via script rather than an ini file does. The architecture of web servers is drasticly changed from the days of IIS3/4. You can load seperate instances of and isapi module for different web servers. So a web server running php scripts that only need the imap module for instance, would not need to load a dozen other modules needed by a different web server. > It's basically the same as loading them in php.ini, > but not doing it in php.ini. I can't find a very good reason for doing > that (other than the unexplained hatred towards php.ini :). The > performance and stability problems that affect dl() will not affect this > feature, but the security implications will. ini is a general pain for others as well, it's not just an extension issue. > >Arbitrary code? extension_dir defines where you can load from, and you > >can only load dll's that exist within that. > > Security is a relative term. There's no absolute security, and there are a > zillion different degrees of security. By adding dl(), you degrade PHP's > level of security because you bring the danger closer. With dl(), all the > user has to do in order to exploit your server is figure out a way to put > exploit code in a certain directory, and voila. Without it - he has no way > of loading executable code into the server, no matter what. From a > security perspective, there's no question that adding it degrades security, > the only question is how much. First, this ignores the fact that paranoid sysadmins, or ISP's which should be paranoid, can dissable dl, and load whatever is necessary into php.ini. This also takes for granted that the user has already exploited the system and gained access necessary to put executable code on the server. If the user has gotten that far, it doesn't matter what php does or does not do. If the user has that much access, they can put a dl in the extension_dir and modify php.ini. Next time the web server starts, exploitable code is loaded. dl makes no difference here. > > > Additionally, the dl > >loading > >code looks for specific exports to even be able to load the dll. > > Well, they're quite easy to implement. That's beside the point. The point being that a number of steps must occure for code to be exploitable via dl. > > The > >only security issue is if the administrator puts arbitrary dll's into > >the path defined by extension_dir. The really paranoid can disable the > >function in php.ini. If you're worried about security issues with dl, > >we should all be much more fearful of the COM, Corba and .Net > >extensions. > > COM, Corba and .NET give you accessibility to objects that are already > installed on the system, with whatever permissions and policies that are > enforced by their installation. dl() gives you a way of doing all sorts of > nasty things within the web server. I don't pretend to know what can be > done using dl(), as I don't spend my days trying to figure out exploits. I > know that it's bad security wise, and to say the least, it doesn't sound > unreasonable that it's exploitable. And, at least under IIS, you have the option of configuration file system level security for any dll. dl() does not give any way to do anything nasty, other than allowing a dll to be loaded. > >I just find it more than slightly sad that PHP cannot dynamicly load > >extensions when Perl, Python, and other script languages don't have > >problems with this, and are in fact designed to do it that way to begin > >with. I think it's very short sighted to not have this ability. > > Neither Python nor Perl were designed as server plugins, definitely not > multithreaded server plugins. IMHO adding dl() to PHP in the first place, > a-la Perl, was short-sighted because it really doesn't fit a server > plugin. It wasn't too evident while we were using Apache/1.x under UNIX, > but with PHP 4 and the multithreaded support it became much > clearer. Getting dl() to work in a multithreaded environment is probably > just a few days' work, but I see this in the opposite way from you - I > think it would be short sighted to support it. The sooner we deprecate it, > the better, and effectively, dl() has been dead under Windows for a very, > very long time, with very little complaints. First, Perl is used twice as much as PHP under Apache on top web sites (*). Python supports threading much better than Perl or PHP. Dynamic loading is a core component in extension writing in both languages. Both Perl and Python are used extensivly for server side work, and Perl is very prevelent as web server plugins, and it is used quite a lot under IIS as a multithreaded plugin. Irregardless of the initial design of Perl, the fact is that it is used in this situation a lot, and does have this capability. > > But > >I'm not going to waste any more of my time on it. > > Good :) Sorry, couldn't avoid continuing the argument! :) But two points seem to come out of this. a - the unloading of the dl is the major cause of problems b - it is fixable Shane (*) A few months back I found a little script that scans through 120 or so of the "top" sites on the internet. I haven't verified that they are indeed the "top" sites, but the names are big :). The numbers came out to be something around 35% for both apache and iis, the remaining a mix of servers. Apache/mod_perl was around 15%, and mod_php at 7-8%. That is of course, for those systems that exposed that information, but it's essentialy the same method used to get our monthly numbers. -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
