note 46133 added to tutorial.firstpage

If PHP is running under Apache, there are very different ways to tell Apache what's a PHP script and whether it should be executed. If you can, locate the httpd.conf and look for the appropriate settings; if you can't, ask your site administrator. The options are: 1) Make Apache interpret any PHP files it finds and serve them like HTML. This kind of set-up is rare, as it is extremely unsafe. PHP "safe mode" is intended to give some measure of protection in such situations, but it doesn't even approach that of setup (3b), below (safe mode is over-restrictive in some areas and not restrictive enough in others, and too many PHP scripts will break in safe mode anyway, so I decided against it - YMMV). 2) Make Apache interpret PHP files only if they are found in some specific URL area (usually /cgi-bin/whatever). This doesn't help in protecting different users from each other, but it makes it more obvious if, say, a file upload would overwrite a script. (It's not a real protective measure though. File uploads shouldn't be permitted except into specially designated data directories with a .htaccess file that disallows script execution of any kind. Actually this applies to any kind of file creation, e.g. many Wikis allow the user to type in a topic name and will create a text file with that name - so the directory in which the name is created should be made non-executable.) 3) Make Apache hand over .php, .sh, .pl etc. etc. to the Unix shell for interpretation. This has the advantage that Apache can use the "suEXEC" mechanism, which allows it to impersonate some other user than the standard "nobody" or "www-data". For example, if multiple users are allowed to create PHP scripts on the same server, the server administrator will create a separate user account for each, and have Apache impersonate the appropriate account. Unfortunately, this setup gives up a large amount of efficiency, which means that the hoster has to set up a larger machine for the same load. In other words, hosting accounts will be a bit more expensive but *far* more safe. 3a) A badly-configured setup of this kind will require that you insert a line like "#! /usr/bin/php4" at the top of each PHP file. Of course, this is simply too much work for even modest amounts of PHP on a site, but some (few) sites require this anyway. 3b) A better-configured setup will recognize file types from the file extension (just as Windows does it). If you have a (3a)-style setup and know or suspect your provider has a Linux box running, talk to him about the binfmt_misc extension. It requires about a hour to install properly and (possibly) a kernel recompilation (that's another hour or two if they are just running preinstalled boxes, and a near-zero overhead if they're installing their machines anyway). Most sites combine setup (2) with safe mode. In that case, do a regular backup of everything that you have on the server, since your site is open to attacks from script kiddies that live on the same machine. (Source Forge had incidents of that kind.) (Note that this kind of problem applies to Perl scripts, or any kind of scripting that can create or overwrite files. For example, the TWiki site on SourceForge got clobbered by this at least once - well, SourceForge is particularly vulnerable to this because anybody with a browser and pretending to do open source development will be allowed to upload CGI scripts.) ---- Manual Page -- http://www.php.net/manual/en/tutorial.firstpage.php Edit -- http://master.php.net/manage/user-notes.php?action=edit+46133 Delete -- http://master.php.net/manage/user-notes.php?action=delete+46133&report=yes Reject -- http://master.php.net/manage/user-notes.php?action=reject+46133&report=yes Search -- http://master.php.net/manage/user-notes.php