Re: [PHP-DEV] the dl() issue
Hi Stig, On Thu, Mar 21, 2002 at 10:00:48AM +0100, Stig S. Bakken wrote: I just asked a friend of mine who is using Pair if he could dl() modules. Pair give users their own extension_dir, but no access to php.ini, and no way of reloading the server (which would still be required for an auto-load extension dir). So for Pair users, dl() is currently the _only_ way to load third-party extensions. The reason Pair do this, according to my friend, is that in case Apache crashes, they will at last know what modules were loaded for all processes, only the processes that run PHP scripts doing dl() will crash because of bugs in the 3rd party extensions. Following this train of thought, an auto-load extension folder would not be a solution either, because it would still lead to the additional vulnerability to Apache processes that Pair avoid this way. I think we should bring in some people from hosting companies into this discussion, to make sure we have all the facts right. Right now we are assuming a bit too much. Saw this message in the archive, and figured I might as well throw in my two cents. My own background is that I'm a webmaster and sysadmin for a (PHP-friendly) regional ISP/hosting company in the US. I'm also currently involved in preparation of the PHP binaries that Debian ships, which means I get to hear about it any time those binaries don't work. I would be so bold as to guess that roughly 35-40% of the show-stopper bug reports I've seen relating to the Debian PHP packages involve problems with conflicting libraries. This percentage has gone down quite a bit in the past year, mostly due to the work of Petr Cech before me; but there are still problems that show up periodically as segfaults either at Apache load time or during script execution. And unfortunately, most of these segfaults are caused by conflicts between various libraries that are *dependencies* of PHP extenions, not by the PHP extensions themselves, which makes it hard to find a general solution to the problem; it takes someone standing by ready to play whack-a-bug every time these issues show up. Now, my employer has it relatively easy -- they have a webmaster who, ah, 'enjoys' playing with gdb, and these library conflicts are worked out long before they ever reach our production system. Others might not be so lucky as to be using Debian on their webservers. ;) Enter dl(), stage left. If you have five different websites on your server, each of which makes use of two different PHP extensions that are compiled as shared modules, I'm sorry to say that there's a not insignificant chance that you'll never get Apache to start without segfaulting if you list all of those extensions in your php.ini. But, if you enable each of those customers to use dl(), there's a pretty good chance (assuming sane library loading/unloading behavior on PHP's part) that all of the sites can happily coexist. It may not be pretty, but until there's a general solution to the sort of complex library dependency problems that are likely to arise on ELF platforms (Linux in particular), I believe it's necessary. Oh, and all the talk in this thread about security is a red herring. Really now, installing arbitrary modules into extension_dir just so you can dl() them? If the hosting environment's properly configured, the attacker's not going to be able to write to that directory; and by the time they get write access to that directory, there are lots of easier attacks that they can mount against the system -- like editing php.ini directly, or *replacing* an exiting .so that's already being referenced. Having a world-writable extension_dir filled with read-only files is such an edge-case in the land of bizarre configuration errors that it's certainly not worth preventing at the expense of those who have genuine uses for dl(). Cheers, Steve Langasek postmodern programmer msg36144/pgp0.pgp Description: PGP signature
Re: [PHP-DEV] the dl() issue
I just asked a friend of mine who is using Pair if he could dl() modules. Pair give users their own extension_dir, but no access to php.ini, and no way of reloading the server (which would still be required for an auto-load extension dir). So for Pair users, dl() is currently the _only_ way to load third-party extensions. The reason Pair do this, according to my friend, is that in case Apache crashes, they will at last know what modules were loaded for all processes, only the processes that run PHP scripts doing dl() will crash because of bugs in the 3rd party extensions. Following this train of thought, an auto-load extension folder would not be a solution either, because it would still lead to the additional vulnerability to Apache processes that Pair avoid this way. I think we should bring in some people from hosting companies into this discussion, to make sure we have all the facts right. Right now we are assuming a bit too much. - Stig On Tue, 2002-03-12 at 12:01, Zeev Suraski wrote: That sounds like a pretty good idea, actually :) Zeev At 11:32 AM 3/12/2002, Stanislav Malyshev wrote: MK For them, digging into the guts of the system, installing PHP MK extensions there and modifying obscure, Apple-supplied configuration MK files is MUCH, MUCH more frightening than just downloading a php MK extension, dropping it into the Sites folder in their home directory, MK and calling dl(extension.bundle); in their PHP scripts. Might the solution be in the form of some 'auto-load extension folder'? I.e., folder in which all extensions found there are loaded automatically? -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/ +972-3-6139665 ext.115 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] the dl() issue
A user should be able to use auto_prepend_file option in their .htaccess code to automatically load the extensions they need using dl(). In effect that would be the same thing as an auto_load extension folder no? Ilia On March 21, 2002 04:00 am, Stig S. Bakken wrote: I just asked a friend of mine who is using Pair if he could dl() modules. Pair give users their own extension_dir, but no access to php.ini, and no way of reloading the server (which would still be required for an auto-load extension dir). So for Pair users, dl() is currently the _only_ way to load third-party extensions. The reason Pair do this, according to my friend, is that in case Apache crashes, they will at last know what modules were loaded for all processes, only the processes that run PHP scripts doing dl() will crash because of bugs in the 3rd party extensions. Following this train of thought, an auto-load extension folder would not be a solution either, because it would still lead to the additional vulnerability to Apache processes that Pair avoid this way. I think we should bring in some people from hosting companies into this discussion, to make sure we have all the facts right. Right now we are assuming a bit too much. - Stig On Tue, 2002-03-12 at 12:01, Zeev Suraski wrote: That sounds like a pretty good idea, actually :) Zeev At 11:32 AM 3/12/2002, Stanislav Malyshev wrote: MK For them, digging into the guts of the system, installing PHP MK extensions there and modifying obscure, Apple-supplied configuration MK files is MUCH, MUCH more frightening than just downloading a php MK extension, dropping it into the Sites folder in their home directory, MK and calling dl(extension.bundle); in their PHP scripts. Might the solution be in the form of some 'auto-load extension folder'? I.e., folder in which all extensions found there are loaded automatically? -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/ +972-3-6139665 ext.115 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] the dl() issue
On Wed, 2002-03-13 at 22:08, Zeev Suraski wrote: At 21:36 13/03/2002, Shane Caraveo wrote: I thought we weren't wasting any more time with this? :) Yeah, I'm getting realy tired of having to argue for something that should be a base part of the language. Kodus on the tactics :) I understand Shane's point of view very well here. PHP _needs_ a way of loading modules at runtime, not some half-solution like preloading from php.ini or directories where everything is preloaded. I had given up on this one until Shane popped out of the woodwork. What I don't understand is your insisting on that dynamically loading extensions at runtime in PHP is not possible, when it is possible in for example Perl running as a MT server plugin. It just doesn't make sense. If you don't have enough interest in runtime loading to find time to implement it, that's fine, but please say so instead of fighting the whole idea. Both Shane and I have enough interst to make an effort. - Stig -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] the dl() issue
At 01:08 AM 3/16/2002 +0100, Stig S. Bakken wrote: On Wed, 2002-03-13 at 22:08, Zeev Suraski wrote: At 21:36 13/03/2002, Shane Caraveo wrote: I thought we weren't wasting any more time with this? :) Yeah, I'm getting realy tired of having to argue for something that should be a base part of the language. Kodus on the tactics :) I understand Shane's point of view very well here. PHP _needs_ a way of loading modules at runtime, not some half-solution like preloading from php.ini or directories where everything is preloaded. I had given up on this one until Shane popped out of the woodwork. Stig, It doesn't *need* a way of loading modules at run-time. I completely disagree with that as I believe that the ability to load shared objects at server startup is more than enough. Except for you guys thinking it's cool I don't think it's something which is desperately needed. Personally even if PHP had the ability of dynamically loading at run-time I wouldn't use it. I always prefer setting up my environment in a deterministic way. What I don't understand is your insisting on that dynamically loading extensions at runtime in PHP is not possible, when it is possible in for example Perl running as a MT server plugin. It just doesn't make sense. If you don't have enough interest in runtime loading to find time to implement it, that's fine, but please say so instead of fighting the whole idea. Both Shane and I have enough interst to make an effort. Everything is possible but the way PHP works right now it's extremely difficult. I think you guys often exaggerate on the desperate need of stuff. There is a reason why hundreds of thousands of PHP users haven't begged for it. Most people don't miss it... Also I think the never ending comparison of people to Perl Python in lots of aspects not only dynamic loading is getting a bit old. Certain developers here say stuff like Well Perl Python have it and PHP will stink unless it does the same. Maybe it's time to start using Perl Python for those people :) I think PHP gives the users lots of stuff those other two languages don't give. Anyway, I'm not trying to be argumentative but let's try and be a bit more realistic here Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] the dl() issue
I never said it's not possible, I always said that it's going to be inefficient and less stable in MT. Of course I have no plans to implement it, but I also don't think it should be implemented at all; It requires far reaching changes to the infrastructure which would destabilize the MT version of PHP, and make it less efficient. You can give it a try of course, I'm just warning you in advance :) I don't see why you call preloading from php.ini or registry or autoloading 'half solutions'. It works fine for IIS, Apache and plenty of other applications I came across. Of course Perl supports it, so what? It made a shift from a command line tool that was virtually based on loading modules, it had to.We don't. Zeev At 02:08 16/03/2002, Stig S. Bakken wrote: On Wed, 2002-03-13 at 22:08, Zeev Suraski wrote: At 21:36 13/03/2002, Shane Caraveo wrote: I thought we weren't wasting any more time with this? :) Yeah, I'm getting realy tired of having to argue for something that should be a base part of the language. Kodus on the tactics :) I understand Shane's point of view very well here. PHP _needs_ a way of loading modules at runtime, not some half-solution like preloading from php.ini or directories where everything is preloaded. I had given up on this one until Shane popped out of the woodwork. What I don't understand is your insisting on that dynamically loading extensions at runtime in PHP is not possible, when it is possible in for example Perl running as a MT server plugin. It just doesn't make sense. If you don't have enough interest in runtime loading to find time to implement it, that's fine, but please say so instead of fighting the whole idea. Both Shane and I have enough interst to make an effort. - Stig -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] the dl() issue
On Sat, Mar 16, 2002 at 02:28:52AM +0200, Zeev Suraski wrote : I never said it's not possible, I always said that it's going to be inefficient and less stable in MT. Of course I have no plans to implement it, but I also don't think it should be implemented at all; It requires far reaching changes to the infrastructure which would destabilize the MT version of PHP, and make it less efficient. You can give it a try of course, I'm just warning you in advance :) I don't see why you call preloading from php.ini or registry or autoloading 'half solutions'. It works fine for IIS, Apache and plenty of other applications I came across. None of them is actually a) a scripting language b) which is used other environments than the web. Of course Perl supports it, so what? So what? Because it's not only for 'web things' and therefore it makes sense. Nobody can't deny PHP is not used to off-web application. My personal view is that I don't need to see dl() ability for MT server but for general scripting use of PHP. - Markus -- Please always Cc to me when replying to me on the lists. GnuPG Key: http://guru.josefine.at/~mfischer/C2272BD0.asc -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] the dl() issue
I thought we weren't wasting any more time with this? :) At 10:54 PM 3/12/2002, Shane Caraveo wrote: 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. It's actually not the primary reason at all. Either I completely don't understand you, or you simply don't understand dl(), or you don't mind violating one of the basic rules of PHP. If it's option #1, please try to explain again what you mean... About option #2 - dl() right now, affects the current process (or thread) only. If you're talking about something which will change PHP process-wide, then you are not talking about dl(), but about something else. About option #3 - if you think dl() should go on working according to its spec, only not clean up after itself (i.e., load into the current process/thread only, but stay there at the end of the request), then you're violating one of the basic concepts of PHP - clean up *everything* after a request, and have all of the processes/threads in the pool 'equal'. If you're talking about adding a function that will essentially do what extension= does in php.ini, only at runtime (i.e., load the module process-wide, and have it stay there), then you're still violating a basic rule in PHP (pages will behave differently according to whether or not a page with the loading statement has been accessed). In all of what you said, I haven't heard any explanation to why you've grown to hate php.ini, and frankly, I think that php.ini is more than sufficient. With Stas's idea of an auto-load directory, even the complaints of the text-editor-challenged users will be answered. In a retaliatory preemptive attempt to end this thread, I also took the liberty to snip away the rest of your post and end it here, except for one comment: First, Perl is used twice as much as PHP under Apache on top web sites (*). I'll take the liberty to consider this statement quite baseless, given the information I've seen. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] the dl() issue
I thought we weren't wasting any more time with this? :) Yeah, I'm getting realy tired of having to argue for something that should be a base part of the language. So let me explain this an entirely different way. Lets forget about dl() altogether for just a second so we can focus instead on the issue I am trying to get through to you. What module/extension developers need is a way to effectively write extensions that are mixed PHP/C/C++. The PHP part needs some way to say 'hey php engine, you have to load xxx.dll now'. This should NOT be reliant on php.ini. If a module/extension is placed into an include/extension path directory (defined in the php.ini), it should be considered fair game to be loaded at ANY time by php. C code loaded at any given point should remain loaded until the process exits (this deals with performance issues). Having this feature solves several issues for everyone: 1. no reliance on a single configuration on a system where multiple configurations are desirable 2. ease of use and installation for php users 3. ease of distribution for developers 4. you no longer have to have multiple php.ini files for different configurations. In all of what you said, I haven't heard any explanation to why you've grown to hate php.ini, and frankly, I think that php.ini is more than sufficient. I think I've been fairly fair to php.ini in saying there are definitly things it should be used for, and 'preloading' extensions is handled there quite nicely, but we still need a runtime method. My dislike for it is that it makes having multiple configurations more difficult. I think a basic difference of opinion here is that you feel php.ini is fine, I find it limiting and anoying for multiple configuration systems. If you're talking about adding a function that will essentially do what extension= does in php.ini, only at runtime (i.e., load the module process-wide, and have it stay there), then you're still violating a basic rule in PHP (pages will behave differently according to whether or not a page with the loading statement has been accessed). That's such a non issue. You get an error just like you do now if a module is not loaded and you try to use it. Anyway, a year ago I probably would agree with you about this, but having had other scripting langugages thrust into my life, I've learned to realy appreciate some of the basic things about them, one being that I do not have to go and change a central configuration of the language itself evertime I want to load a different extension. With Stas's idea of an auto-load directory, even the complaints of the text-editor-challenged users will be answered. I actually realy dislike that idea. It's no different than having to put something in php.ini. All the dll's get loaded for any instance of PHP unless you have seperate autoload directories for seperate configurations. It just gets more and more into hairy config situations, which is what I am trying to avoid. In a retaliatory preemptive attempt to end this thread, I also took the liberty to snip away the rest of your post and end it here, except for one comment: First, Perl is used twice as much as PHP under Apache on top web sites (*). I'll take the liberty to consider this statement quite baseless, given the information I've seen. Taking away the context in which it was responding to does indeed make it quite baseless, because it's not about how much Perl is used anywhere. I made the point that Perl and Python both allow for dynamicly loaded modules, you said they are not designed for web server use, especially in multithreaded situations, and I replied with the fact that Perl is used twice as much on top sites, and Python is much better at threading that either Perl or PHP. Context in conversasion is quite important. Shane -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] the dl() issue
At 21:36 13/03/2002, Shane Caraveo wrote: I thought we weren't wasting any more time with this? :) Yeah, I'm getting realy tired of having to argue for something that should be a base part of the language. Kodus on the tactics :) Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] the dl() issue
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
Re: [PHP-DEV] the dl() issue
MK For them, digging into the guts of the system, installing PHP MK extensions there and modifying obscure, Apple-supplied configuration MK files is MUCH, MUCH more frightening than just downloading a php MK extension, dropping it into the Sites folder in their home directory, MK and calling dl(extension.bundle); in their PHP scripts. Might the solution be in the form of some 'auto-load extension folder'? I.e., folder in which all extensions found there are loaded automatically? -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/ +972-3-6139665 ext.115 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] the dl() issue
That sounds like a pretty good idea, actually :) Zeev At 11:32 AM 3/12/2002, Stanislav Malyshev wrote: MK For them, digging into the guts of the system, installing PHP MK extensions there and modifying obscure, Apple-supplied configuration MK files is MUCH, MUCH more frightening than just downloading a php MK extension, dropping it into the Sites folder in their home directory, MK and calling dl(extension.bundle); in their PHP scripts. Might the solution be in the form of some 'auto-load extension folder'? I.e., folder in which all extensions found there are loaded automatically? -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/ +972-3-6139665 ext.115 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] the dl() issue
Zeev and Stas: That sounds like a pretty good idea, actually :) Might the solution be in the form of some 'auto-load extension folder'? I.e., folder in which all extensions found there are loaded automatically? Yes, this seems to be a near-perfect solution to me. Great! --Marko -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] the dl() issue
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
Re: [PHP-DEV] the dl() issue
Marko Karppinen wrote: Zeev and Stas: That sounds like a pretty good idea, actually :) Might the solution be in the form of some 'auto-load extension folder'? I.e., folder in which all extensions found there are loaded automatically? Yes, this seems to be a near-perfect solution to me. Great! +1 -- Yasuo Ohgaki [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] the dl() issue
Shane wrote: I think dl is an extremely important feature, and issues surrounding it should be fixed. I'm absolutely, positively +1 on this. On the Mac OS X side of things, we are in the interesting situation of having PHP bundled with the operating system. I guess the same can be said about various Linux distributions, but there is a crucial difference: On the Mac, there is a tremendous pressure to leave the Apple-supplied software alone -- this will guarantee that it will remain upgradeable with Apple's Software Update mechanism, for example. Now Apple obviously can't bundle each and every PHP extension on the operating system CD-ROMs and preconfigured Macs. Currently, this is a lose-lose situation: The Apple-supplied PHP version doesn't have the features you need, and if you replace it with a homegrown PHP, you lose Apple's automatic updates and support. Having a good, working dl mechanism is the only reasonable way out of this Catch-22. Marko -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] the dl() issue
At 11:42 11/03/2002 +0200, Marko Karppinen wrote: Shane wrote: I think dl is an extremely important feature, and issues surrounding it should be fixed. I'm absolutely, positively +1 on this. On the Mac OS X side of things, we are in the interesting situation of having PHP bundled with the operating system. I guess the same can be said about various Linux distributions, but there is a crucial difference: On the Mac, there is a tremendous pressure to leave the Apple-supplied software alone -- this will guarantee that it will remain upgradeable with Apple's Software Update mechanism, for example. Now Apple obviously can't bundle each and every PHP extension on the operating system CD-ROMs and preconfigured Macs. Currently, this is a lose-lose situation: The Apple-supplied PHP version doesn't have the features you need, and if you replace it with a homegrown PHP, you lose Apple's automatic updates and support. Having a good, working dl mechanism is the only reasonable way out of this Catch-22. Apple should be using php.ini for extensions and not require the user to call dl() wich is sucky. I still am not quite sure why it's such a big deal to add shared extensions to php.ini. I don't agree that PHP extensions necessarily require dl(). There are many programs out there in the computer industry (such as Apache) which require you to add extensions in an INI file. Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] the dl() issue
On Mon, Mar 11, 2002 at 08:49:11PM +0200, Andi Gutmans wrote : At 11:42 11/03/2002 +0200, Marko Karppinen wrote: Shane wrote: I think dl is an extremely important feature, and issues surrounding it should be fixed. I'm absolutely, positively +1 on this. On the Mac OS X side of things, we are in the interesting situation of having PHP bundled with the operating system. I guess the same can be said about various Linux distributions, but there is a crucial difference: On the Mac, there is a tremendous pressure to leave the Apple-supplied software alone -- this will guarantee that it will remain upgradeable with Apple's Software Update mechanism, for example. Now Apple obviously can't bundle each and every PHP extension on the operating system CD-ROMs and preconfigured Macs. Currently, this is a lose-lose situation: The Apple-supplied PHP version doesn't have the features you need, and if you replace it with a homegrown PHP, you lose Apple's automatic updates and support. Having a good, working dl mechanism is the only reasonable way out of this Catch-22. Apple should be using php.ini for extensions and not require the user to call dl() wich is sucky. I still am not quite sure why it's such a big deal to add shared extensions to php.ini. I don't agree that PHP extensions necessarily require dl(). There are many programs out there in the computer industry (such as Apache) which require you to add extensions in an INI file. Hehe .. yeah, but then, apache isn't that often used as a scripting language from the command line X-) - Markus -- Please always Cc to me when replying to me on the lists. GnuPG Key: http://guru.josefine.at/~mfischer/C2272BD0.asc -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] the dl() issue
Having a good, working dl mechanism is the only reasonable way out of this Catch-22. Apple should be using php.ini for extensions and not require the user to call dl() wich is sucky. This is not about what Apple should be doing; indeed, Apple does nothing to stop you from using a php.ini file. The question is this: what will the *users* of Apple computers be doing? For them, digging into the guts of the system, installing PHP extensions there and modifying obscure, Apple-supplied configuration files is MUCH, MUCH more frightening than just downloading a php extension, dropping it into the Sites folder in their home directory, and calling dl(extension.bundle); in their PHP scripts. The fact that we're bundled on OS X has the promise of making PHP available to a whole new group of users. Leveraging that will require special consideration from us. Mac users don't become UNIX users just by installing OS X, and we shouldn't expect them to. --Marko -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] the dl() issue
Apple should be using php.ini for extensions and not require the user to call dl() wich is sucky. I still am not quite sure why it's such a big deal to add shared extensions to php.ini. I don't agree that PHP extensions necessarily require dl(). There are many programs out there in the computer industry (such as Apache) which require you to add extensions in an INI file. ?? Perhaps I'm confused here, but using dl() or calling a module in the php.ini file is handled in approximately the same way. In one, the module is loaded at the start, and unloaded when PHP is stopped. And in two, the module is loaded by the script and unloaded when the script is finished. No matter what, you'll still have to use dlopen, dlsym, dlclose to accomplish this. Apple provides emulation dlopen, dlsym, dlclose wrappers for their functions to load dynamic shared objects. Just patching that apple-provided source into the PHP distribution should be fairly painless, and resolve all these issues. I could look into doing this if someone hasn't already in CVS. The one thing to remember is that MACH-O kernel differentiates between a library that is linked and a library that is dynamically opened. Hence *.dylib vs *.so ... AFAIK the APPLE OS X is the only OS that does this, it's a real PITA. - Brad House Sr. Developer Main Street Softworks, Inc. [EMAIL PROTECTED] (352) 378-8228 - -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] the dl() issue
At 21:08 11/03/2002 +0200, Marko Karppinen wrote: Having a good, working dl mechanism is the only reasonable way out of this Catch-22. Apple should be using php.ini for extensions and not require the user to call dl() wich is sucky. This is not about what Apple should be doing; indeed, Apple does nothing to stop you from using a php.ini file. The question is this: what will the *users* of Apple computers be doing? For them, digging into the guts of the system, installing PHP extensions there and modifying obscure, Apple-supplied configuration files is MUCH, MUCH more frightening than just downloading a php extension, dropping it into the Sites folder in their home directory, and calling dl(extension.bundle); in their PHP scripts. The fact that we're bundled on OS X has the promise of making PHP available to a whole new group of users. Leveraging that will require special consideration from us. Mac users don't become UNIX users just by installing OS X, and we shouldn't expect them to. I'm surprised that MAC OS X's installation/update program doesn't know how to edit text files :) Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] the dl() issue
At 14:03 11/03/2002 -0500, Brad House wrote: Apple should be using php.ini for extensions and not require the user to call dl() wich is sucky. I still am not quite sure why it's such a big deal to add shared extensions to php.ini. I don't agree that PHP extensions necessarily require dl(). There are many programs out there in the computer industry (such as Apache) which require you to add extensions in an INI file. ?? Perhaps I'm confused here, but using dl() or calling a module in the php.ini file is handled in approximately the same way. In one, the module is loaded at the start, and unloaded when PHP is stopped. And in two, the module is loaded by the script and unloaded when the script is finished. The problem isn't MAC OS X. The problem is that PHP's dl() call has certain problems and it is especially hard to get it working in multi-threaded builds. Personally I don't have very much motivation to fix it because I think it sucks anyway :) Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] the dl() issue
At 11:42 11/03/2002 +0200, Marko Karppinen wrote: Shane wrote: I think dl is an extremely important feature, and issues surrounding it should be fixed. I'm absolutely, positively +1 on this. On the Mac OS X side of things, we are in the interesting situation of Apple should be using php.ini for extensions and not require the user to call dl() wich is sucky. I still am not quite sure why it's such a big deal to add shared extensions to php.ini. I don't agree that PHP extensions necessarily require dl(). There are many programs out there in the computer industry (such as Apache) which require you to add extensions in an INI file. I don't see this as an Apple issue at all, though from the comments I guess it could fix an issue for that platform as well. The issue to me is a matter of usability. I want to have a single installation of PHP, but may have many different situations under which I use that installation. Perhaps one application uses modules x, y and z extensively, another uses a, b and c extensively, and perhaps d very rarely. Lets say neither uses extensions the other app uses. The current situation is that I must load all extensions in php.ini irregardless of use, or I must use -c to specify an ini file, etc. I prefer not to load extensions unless I really need them, but PHP simply does not provide an easy effective means to do that. Perl and Python both do and you never have to think about messing with an ini file. I think far PHP has put far too much reliance on the ini file. Shane -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] the dl() issue
At 10:25 PM 3/11/2002, Shane Caraveo wrote: I prefer not to load extensions unless I really need them Why? If it's performance or stability, than the loss you're paying is roughly 100x more than what you're gaining (yes, it's another one of those out-of-the-pocket numbers, meaning 'a hell of a lot more' :) I don't even want to begin to think about the security implications of this function. Seriously people, please go back to the archives. This dl() issue was discussed in and out about a year ago, and it's been deprecated. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] the dl() issue
At 12:25 11/03/2002 -0800, Shane Caraveo wrote: At 11:42 11/03/2002 +0200, Marko Karppinen wrote: Shane wrote: I think dl is an extremely important feature, and issues surrounding it should be fixed. I'm absolutely, positively +1 on this. On the Mac OS X side of things, we are in the interesting situation of Apple should be using php.ini for extensions and not require the user to call dl() wich is sucky. I still am not quite sure why it's such a big deal to add shared extensions to php.ini. I don't agree that PHP extensions necessarily require dl(). There are many programs out there in the computer industry (such as Apache) which require you to add extensions in an INI file. I don't see this as an Apple issue at all, though from the comments I guess it could fix an issue for that platform as well. The issue to me is a matter of usability. I want to have a single installation of PHP, but may have many different situations under which I use that installation. Perhaps one application uses modules x, y and z extensively, another uses a, b and c extensively, and perhaps d very rarely. Lets say neither uses extensions the other app uses. The current situation is that I must load all extensions in php.ini irregardless of use, or I must use -c to specify an ini file, etc. I prefer not to load extensions unless I really need them, but PHP simply does not provide an easy effective means to do that. Perl and Python both do and you never have to think about messing with an ini file. I think far PHP has put far too much reliance on the ini file. I don't know many production installations where all extensions wouldn't be dl()'ed within a few seconds even if there are what you call *rarely* used scripts. I think your examples are theoretical and the ini change can be done quite easily even by a dumb automatic installation script. In any case, I still think a solution can be found I just don't have any concrete ideas on how to fix it. By the way, you mentioned perl as an example. I have no idea how perl works in multi-threaded environments but if you say it works very nicely with perl multi-threaded servers then I take your word for it. Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] the dl() issue
The issue to me is a matter of usability. I want to have a single installation of PHP, but may have many different situations under which I use that installation. Perhaps one application uses modules x, y and z extensively, another uses a, b and c extensively, and perhaps d very rarely. Lets say neither uses extensions the other app uses. The current situation is that I must load all extensions in php.ini irregardless of use, or I must use -c to specify an ini file, etc. I prefer not to load extensions unless I really need them, but PHP simply does not provide an easy effective means to do that. Perl and Python both do and you never have to think about messing with an ini file. I think far PHP has put far too much reliance on the ini file. I don't know many production installations where all extensions wouldn't be dl()'ed within a few seconds even if there are what you call *rarely* used scripts. I think your examples are theoretical and the ini change can be done quite easily even by a dumb automatic installation script. Only as theoretical as the arguments against dl appear to me, and it doesn't matter if all dl()'d libraries are loaded right away, it matters that dl is extremely more flexible than dealing with php.ini. It's funny, I recall being the one to want php.ini for php3. Now I find it the single most frustrating thing about php. In any case, I still think a solution can be found I just don't have any concrete ideas on how to fix it. Thus why I wanted to reopen this discussion. I think a solution can be found, and I don't feel it's right to shut out the issue because a 'solution' exists in the ini file, or because of unexplained claims of performance, stability and security issues. Without real thought on it, and a real explaination of the issues, no solution will be found. The only valid explaination I found was that the module init ends up getting called twice, resulting in a performance issue. There was something else about garbage collection of classes. That kind of information is the kind that is important to know. Concrete issues are fixable. Of course loading libraries at run time are going to be slower performing and non-optimizable in certain situations. Dynamicaly loading anything is, and we dynamicly load everything. I cannot imagin any real concrete reasons against dl. Any previous archive email about dl I read failed to convince me that dl should be deprecated. By the way, you mentioned perl as an example. I have no idea how perl works in multi-threaded environments but if you say it works very nicely with perl multi-threaded servers then I take your word for it. I have worked on a multi-threaded perl server at work (PerlEx). There is no issue with dynamic loading of modules unless, of course, they are not thread safe. Dynamic loaded modules remain loaded until the interpreter is shut down, so there is no performance issue except on the first load. Commonly loaded modules can be preloaded to avoid the initial hit during script execution. Shane -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
