Live Chat Software by Kayako
Posted by Ahman donk on 21 April 2008 04:19 AM
*** THE FOLLOWING BELOW IS A HOW-TO GUIDE ONLY IF YOU|
ARE HAVING ISSUES WITH YOUR WITH THE SECURITY MEASURES
USED ON THIS SERVER MAINLY PHPSUEXEC SUPPORT ***
The Golden Rules To Which You Must Adhere
1. Ensure script permissions are correct. Any script that is world-writable (i.e. permissions with 0777) will not
execute. Neither will they execute from a directory that has such permissions.
The maximum workable permissions are 0755 for both directories and scripts. Change these in your ftp client by
right clicking on the file or directory and then select 'Properties'.
2. Ensure ownership of files are correct. Directories (not including the public_html directory) and files must be owned
by user:user not nobody:nobody. In general most scripts would be already owned by user:user, however files created
by PHP may have a different ownership set. Support will change these at the server level but check them if you have
3. Ensure that scripts are uploaded in ASCII and not BINARY mode when transferring files by ftp. If in doubt, delete and
re upload - this one generally gives you a 'premature end of headers' type error.
4. If you are using .htaccess with a php_value or a php_flag entry within it, you will receive an error when attempting
to access the scripts. Apache will not recognise these commands and produce an error page.
All PHP values should be removed from your .htaccess files to avoid any complications. Adding a php.ini file in its
place will solve this issue.
For example, if you previously had this setting in your directories .htaccess file:
php_value some_directive On
then remove it from the .htaccess file.
Now create and add in this to your new php.ini file:
and place the php.ini file in the same directory.
Q. What is a php.ini file and how do I go about making one?
A. The php.ini file is a configuration file that the server looks at to see what options have been modified from the
default server configuration. While the name may seem advanced to those unfamiliar with it, it's simply a text
file with the name php.ini
Q. How do I create a php.ini file?
A. To create a php.ini file, just open up a *TEXT* editor (such as Notepad, Editplus, Wordpad - or even use the Cpanel
FileManager option to create a new file - do not use a word processor!), add in the lines you need and save the file.
You can name the file whatever you wish when saving.
Once done, upload the file to the directory where the script you're using is being accessed. Rename it to php.ini if you
changed it on save (some clients use a .txt extension so the ftp client will not be confused between ASCII and BINARY).
Q. But won't somebody be able to pull up the php.ini file in their web browser?
A. You can set the file permissions to "600" (which will allow you to read and write to the file, but will block
Apache from displaying it) and as an added security measure you could add the following in a .htaccess file (such as in
/public_html/.htaccess) to block access:
Deny from All
5. To run html pages with php embedded into them put these commands into the .htaccess file in the public_html folder for your domain
and log into your cpanel then into the apache handlers section and add .htm and .html as server-parsed. This will enable you to use
embedded php inside .htm and .html files while using phpsuexec
For mime if AddType doesn't work you could try AddHandler:
AddHandler application/x-httpd-php .php .html .php3 .php4
1. Here's a short list of the technical limitations:
* The user executing the wrapper must be a valid user on
* The command that the request wishes to execute must not
contain a /.
* The command being executed must reside under your web
* The current working directory must be a directory.
* The current working directory must not be writable by
group or other.
* The command being executed cannot be a symbolic link.
* The command being executed cannot be writable by group or
* The command being executed cannot be a setuid or setgid
* The target UID and GID must be a valid user and group on
* The target UID and GID to execute as, must match the UID
and GID of the directory the script is located within.
* The target execution UID and GID must not be the
privileged ID 0 (root)
* Group access list is set to NOGROUP and the command is
2. Zend Optimizer is still installed, and will continue to
work as it always did.
3. PHP-based HTTP Authentication may cease to function
4. The $PATH_INFO, and $PHP_SELF variable within PHP does not function. What this is used for usually is to make
'search engine friendly' URL's such as in OSCommerce. It modifies the URL of links that uses a method incompatible
with phpSuexec. You can try replacing your code:
$PHP_SELF = $REQUEST_URI
$url = sprintf("%s%s%s","http://",$HTTP_HOST,$REQUEST_URI);
5. The PHP function getallheaders() does not work - this requires PHP to be installed as a module, directly within
6. PHP directives in .htaccess are not allowed. You would get an internal server error if you try.
7. If you use Movable Type, Movable type may not work when rebuilding the site within a phpSuexec environment.
Essentially, what this means is that after you make a posting in your blog, your site stops functioning. This is
because movable type re-creates the files with the wrong permissions. There's a way to get around this - simply find
the mt.cfg file and look for the following lines:
Remove the # signs in the beginning of the lines, save your file, and try to re-generate your site again. All should be
functional at this point.
In layman terms, these are the benefits:
1. All php scripts will run as the script owner. In the past they run under the user of Apache (nobody). This can lead to
delays in tracking down any errant scripts. With this new addition, we can better react to problems and resolve them
faster for you.
2. Another implication of the first benefit is that spammers will no longer be able to send out emails without imprinting
their user id on the mails. This will hasten the tracking and shutting down of any and all spammers.
3. One of the issues in the past has been that all files uploaded via PHP end up being owned by the Apache (nobody)
user. This prevents the user from manipulating the file or in some cases may even lock out the owner from doing
anything to the file. Now, with this change, all files uploaded will be set to the right owner.
4. It was possible in the old system to make a directory/file in the /tmp folder that was owned by the
Apache (nobody) user. With the switch, it's now stamped with their username and group ID. It makes it easier to track
abuses and abusers.
PHP code inside of html pages will only work if the file is named with a php file extension (filename.php and not
filename.html). You will have to edit other pages that link to filename.html to reflect the php extension change.