The php.ini file under suPHP
While suPHP has various security enhancements over DSO PHP such as  running processes as the user rather than nobody as well as only  allowing 755 folder and 644 file permissions, the option to allow  individual php.ini files is a glaring security concern.
There are several methods that can be used to disallow users to have  their own php.ini files under suPHP. The path you take will depend on  whether you want to allow users to have their own in some circumstances  or to restrict all accounts on the server to the global php.ini file at  /usr/local/lib/php.ini location.
Restrict all accounts to the global php.ini file
To restrict all accounts to the global php.ini file, you would edit the /opt/suphp/etc/suphp.conf file:
Uncomment these lines:
Code:
[phprc_paths]
;Uncommenting these will force all requests to that handler to use the php.ini
;in the specified directory regardless of suPHP_ConfigPath settings.
;application/x-httpd-php=/usr/local/lib/
;application/x-httpd-php4=/usr/local/php4/lib/
;application/x-httpd-php5=/usr/local/lib/
 
To these:
Code:
[phprc_paths]
;Uncommenting these will force all requests to that handler to use the php.ini
;in the specified directory regardless of suPHP_ConfigPath settings.
application/x-httpd-php=/usr/local/lib/
application/x-httpd-php4=/usr/local/php4/lib/
application/x-httpd-php5=/usr/local/lib/
 
Save the file, then restart Apache for good measure. Now, if any  account tries to put suPHP_ConfigPath into their .htaccess file, that  account will return an Internal Server Error until they remove the  .htaccess line. No account will be able to use another php.ini file with  this as the default unless you allow the account in the php.ini file  itself.
If you have PHP 5.3+ and want to allow some accounts to have their own php.ini file
If you have restricted all accounts globally to the  /usr/local/lib/php.ini file and want to have one or more accounts bypass  the restriction, this is possible under PHP 5.3 using the global  php.ini itself.
Method One: Allowing individual user_ini files
In /usr/local/lib/php.ini file, put the following line:
Code:
user_ini.filename = .my.ini
The .my.ini name can be anything. Save the file, then go to the  account you want to allow their own settings and create .my.ini on the  account (it can be anywhere on the account so  /home/username/public_html/.my.ini)
In the .my.ini file, you would be able to put only the changes you want to have such as 
register_globals = On  for that account. Of note, only the PHP_INI_PERDIR and PHP_INI_USER  directives are allowed in this file. Any PHP_INI_SYSTEM directives will  not be changeable there.
Method Two: Putting individual user settings into the global php.ini file
This is the better method in my opinion. At the bottom of  /usr/local/lib/php.ini file, you can actually define individual user  php.ini directives with the path to that user's application:
Code:
[PATH=/home/username/public_html]
register_globals=On
post_max_size=5000M
Here is an example putting that at the bottom of  /usr/local/lib/php.ini for an account. If you try doing this in PHP 5.2,  it will change the global value to the new ones rather than just that  user's as PHP 5.2 doesn't support the path directive. Only PHP 5.3 will  work properly to read the path to the user's application. Under this  method, even PHP_INI_SYSTEM directives are changeable for that account.
Under Method One for the user_ini file, the user does have the ability  to themselves modify directives in their .my.ini file on the account.  Under Method Two for the global php.ini user path directives, only the  administrator of the machine could modify the directives. Of note,  anyone can create their own user_ini file under Method One, but they  would need to know the name in the global php.ini to do so (since you  can call the file anything, so it could be called .guessme.ini instead  and users aren't then likely to know the name to bypass restrictions).
If you are using PHP 5.2 or earlier (PHP 5 only, not tested on PHP 4 nor guaranteed to work on PHP 4)
If you are not using PHP 5.3, then the prior methods will not work. This  then leads instead to the more complicated option to allow some users  to have their own php.ini file and some users to be restricted to the  global php.ini file.
Under this method, you cannot have the phprc_paths uncommented, so you  must have them commented out. As such, you would need to ensure  /opt/suphp/etc/suphp.conf looks like the following for that area:
Code:
[phprc_paths]
;Uncommenting these will force all requests to that handler to use the php.ini
;in the specified directory regardless of suPHP_ConfigPath settings.
;application/x-httpd-php=/usr/local/lib/
;application/x-httpd-php4=/usr/local/php4/lib/
;application/x-httpd-php5=/usr/local/lib/
 
Now, you would need to do the following steps:
1. Restrict all users to the global php.ini
Create the following directory:
Code:
mkdir -p /usr/local/apache/conf/userdata
Create a file in that directory:
Code:
cd /usr/local/apache/conf/userdata
vi suphp_config.conf
In that file, place the following:
Code:
suPHP_ConfigPath /usr/local/lib
Save the file (:wq). The above will restrict all current users to the /usr/local/lib location for the php.ini file.
2. Allowing one user to have an individual php.ini
Create the following directories:
Code:
mkdir -p /usr/local/apache/conf/userdata/std/2/username
Here, 
std is for http. If you are also wanting this for https, you'd also create an 
ssl directory. The 
2 is for Apache 2 and 2.2. If you are using Apache 1.3, you'd use 
1 instead. The 
username is the cPanel username, so replace with the correct username.
In that location, create the file:
Code:
cd /usr/local/apache/conf/userdata/std/2/username
vi suphp_config.conf
In that file, place the following:
Code:
suPHP_ConfigPath /home/username/
Again, replace username with the cPanel username. This will allow  a php.ini file to be placed into /home/username level only. Save the  file (:wq).
3. Adding additional directories
Further directories can be allowed on the user's account who is being  allowed to have a php.ini file. If you change the entry to this in
/usr/local/apache/conf/userdata/std/2/username/suphp_config.conf location:
Code:
suPHP_ConfigPath /home/username/{public_html}/{folder1,folder2}
This allows a php.ini in public_html as well as in public_html/folder1 and public_html/folder2 locations.
4. Checking the changes into httpd.conf
Create a backup of Apache in case you need to revert to it:
Code:
cp /usr/local/apache/conf/httpd.conf
/usr/local/apache/conf/httpd.conf.bak100902
Here 100902 is the date where today is September 2, 2010.
Now, run the following command to verify the includes:
Code:
/scripts/verify_vhost_includes
If each checks out OK, you'd then run this command to check these into the system:
Code:
/scripts/ensure_vhost_includes --all-users
Now, rebuild Apache and restart it (rebuilding isn't entirely  necessary in this instance, but I normally just do it as a precaution to  ensure everything is working fine):
Code:
/scripts/rebuildhttpdconf
/etc/init.d/httpd restart
1. mod_userdir exception
mod_userdir will bypasses the suPHP_ConfigPath restriction for the  global php.ini file. If you have a user with the following url type:
http://hostname/~username/
That url will allow any php.ini files or suPHP_ConfigPath set into  .htaccess to parse under mod_userdir. This is unwanted behavior, and the  only current way I'm aware to prevent it would be to disable  mod_userdir on such a system.
2. New accounts aren't restricted
Any accounts created after you have locked users into the global php.ini  file using the 
 tags around  suPHP_ConfigPath in userdata location will not be restricted to it. Each  time a new account is created, the following must be run after the  account creation to lock that account to the global restriction:
Code:
/scripts/ensure_vhost_includes --all-users
/etc/init.d/httpd restart
Defining the suPHP_ConfigPath line in the VirtualHost entry in  httpd.conf does not restrict the account to using that path if the  
 tags are not around it. Without  those 
 tags, if a user defines the  suPHP_ConfigPath into their .htaccess file on their account in either  /home/user/ or /home/user/public_html, their .htaccess entry will  override the httpd.conf VirtualHost entry. You can only lock users to  the set suPHP_ConfigPath by the previously described method.
REFERENCES
http://forums.cpanel.net/f185/methods-increase-security-suphp-restricting-who-can-use-php-ini-files-167186.html