Chris, Thank you for your insight. Now that I've become aware of safe mode, it appears to substantially restrict many PHP file functions. What's more worrisome though is the disclaimer posted at the top of the PHP safe mode documentation: "This is a still probably incomplete and possibly incorrect listing of the functions limited by safe mode"
Yikes!!!! What other limitations am I to expect. Right now my biggest complaint is safe mode's disabling of set_time_limit. My script is trying to process several thousand records in a MySQL db and often exceeds the default 30 second time limit. I look forward to reading your article, but hope you don't scare the living daylights out of PHP admins without offering constructive alternatives to the exploits you reveal. One final comment. It seems there was some motivation, by the PHP creators, to institute safe mode as a fix to potential security abuses. If that was the case, why weren't the underlying problems be removed or remedied as opposed to letting PHP admins make the call? Best wishes, always, Chris Enabling safe mode seems to "Chris Shiflett" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > > Why do hosting providers (or anyone for that matter) choose to run PHP > > with safe mode enabled? > > > > I've had problems running some of my scripts when safe mode is enabled, > > so now I am seeking a new hosting service because the one I'm with > > claims they cannot turn safe mode off for one account. > > Your Web host is correct. > > I am wrapping up an article for php|architect that will hopefully shed > some more light on this issue, but consider this: > > 1. PHP has many filesystem functions. It can read files, write to files, > list directories, etc. > 2. PHP scripts are executed by the Web server (most of the time), and > thus, they can do whatever the Web server can do. > 3. In order to make your PHP scripts work at all, you must make them > readable by the Web server. > > Add these together, and hopefully it is clear that it's trivial to write a > PHP script that explores the filesystem looking for interesting things. In > fact, I wrote a quick example for this article that I'm writing. On every > server I've studied (that has safe_mode disabled), I can at least > compromise any accounts's database username and password, and because of > the tendency for these to be equivalent to the shell username and > password, I can also usually compromise that as well. > > In addition, many people use PHP's default session configuration and store > their session data in /tmp. Since the Web server has write access to these > session files, not only can I browse through anyone's session data, I can > also modify it as I see fit (including my own, to make myself > administrator of your application or whatever I want). So, an attacker has > the option of hijacking a session or just modifying his own. > > While I'm an ethical person and would never do anything malicious, I don't > trust everyone else to do the same. I personally feel that it is > irresponsible for Web hosts to have safe_mode disabled. > > Of course, the reason they do is that there are far more people who will > notice when something doesn't work (as you have noticed) than those who > will notice that there are serious security holes. If the support > department can't handle the number of complaints about safe_mode, it's > easiest to disable it. > > Hope that helps. > > Chris > > ===== > Chris Shiflett - http://shiflett.org/ > > PHP Security - O'Reilly > Coming mid-2004 > HTTP Developer's Handbook - Sams > http://httphandbook.org/ > PHP Community Site > http://phpcommunity.org/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
