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. 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'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. >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. > Additionally, the dl >loading >code looks for specific exports to even be able to load the dll. Well, they're quite easy to implement. > 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. >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. > But >I'm not going to waste any more of my time on it. Good :) Zeev -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
