Force Users To Use Single Php.ini Under suPHP

[Bullten]

If you have a dedicated server and use it to sell shared hosting then this article is for you. Today I am going to explain how you can force your users to use same php.ini under suPHP by disallowing .htaccess override. Limiting php.ini use will add security to your server and will disallow users to use custom php.ini file by overriding default php settings set by server administrator (root).


How to make it work:

Its very simple to enable this function in server using suPHP. Just by enabling phprc_paths in /opt/suphp/etc/suphp.conf will do the work for you. See the steps below:

vi /opt/suphp/etc/suphp.conf

Find the code below and press I to insert text.

[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/

Remove ( ; ) from the last three lines ie.

application/x-httpd-php=/usr/local/lib/
application/x-httpd-php4=/usr/local/php4/lib/
application/x-httpd-php5=/usr/local/lib/

Now press ESCAPE button and enter :wq to save the file.

Restart Apache

/sbin/service httpd restart

Now Users wont be able to override your default php.ini file.

 

[PeterKelly]

Great Tip! This is implemented on the majority of hosting servers in recent times. With more and more people now looking to attempt to exploit vulnerabilities in servers.

 

[handsonhosting]

Why would you force a user not to be able to change certain PHP variables? Especailly some basic ones such as the timestamps etc.

If you secure your server properly, and isolate certain settings which can not be changed, there should be no reason to restrict other aspects such as the memory limits, upload sizes, timezones, register_globals, etc etc.

Granted there are some areas that you would want to restrict yourself (safe mode) or setting maximum limits for things such as max_execution_time or max_input_times - but overall, why would you want to block your users from those edits?

We see too many hosts with these kinds of restrictions that actually break scripts or shopping carts as a result.

Also, these days, SuPHP isn't needed - you can accomplish the same tasks with FCGI, and with software like 1H, you can really lock down the environments even more.

 

[Bullten]

Choosing shared environment will have many restrictions from providers end and always seen in the play too. One will never limit his security policies of shared server. Well it depends what your shared environment still supports. By limiting features still you can provide support for the script...

If you provide safe mode then too it can be bypassed by creating a php.ini file and a htaccess file which creates another problem for the administrator using suphp and still most of companies are using suphp.

 

[handsonhosting]

still most of companies are using suphp.

This contributes to the growing problems on the internet as whole. People using outdated technology to accomplish the same tasks that newer methods can do much easier (and just as securely).

SuPHP spawns a new process every time a page is loaded. This is not a problem when you're talking about a low traffic website, but when you're talking about sites that are doing traffic (and business), then SuPHP really shouldn't be used as it just drives the load up on the servers.

The same security that SuPHP first offered through the use of phpsuexec years ago can be accomplished using fCGI.

Just might be something worth looking into.

 

[tsak]

Great tip . Thanks for sharing. I think that suphp is the best out that . It has the best security that i have seen.
But it is just my opinion