Methods to Increase Security on suPHP - Restricting who can use php.ini files

cPanelTristan

Quality Assurance Analyst
Staff member
Oct 2, 2010
7,606
33
238
somewhere over the rainbow
cPanel Access Level
Root Administrator
Re: Methods to Increase Security on suPHP - Restricting who can use php.ini

I wondered what you were talking about here. All methods work and should work for the version of PHP intended. Anytime someone has claimed it doesn't work, it was because the user did not properly setup the method or tried it on the wrong PHP version.
 

digiscape

Member
Oct 15, 2003
6
0
151
Re: Methods to Increase Security on suPHP - Restricting who can use php.ini

As you stated in your first post Tristan "PHP 5.2 doesn't support the path directive." this was all I was referring to

I have upgraded to PHP 5.3.13 with Apache 2.2.22, neither method 1 or 2 for PHP 5.3 are working for me

There's really not much you can do wrong using the path directive method
 
Last edited:

cPanelTristan

Quality Assurance Analyst
Staff member
Oct 2, 2010
7,606
33
238
somewhere over the rainbow
cPanel Access Level
Root Administrator
Re: Methods to Increase Security on suPHP - Restricting who can use php.ini

Actually, there is something you can do wrong using the path directive method. First, you could not be using suPHP or FCGI, which isn't likely but it would be something wrong. DSO doesn't support that method.

Next, under suPHP, you could not have done this part:

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/
Then restart Apache after doing so. If you do not modify /opt/suphp/etc/suphp.conf file to restrict to the global php.ini file, then what happens is that users can override your settings in their own individual php.ini files.
 

digiscape

Member
Oct 15, 2003
6
0
151
Re: Methods to Increase Security on suPHP - Restricting who can use php.ini

I'm using suPHP and respective lines uncommented in /opt/suphp/etc/suphp.conf to force users to use global ini

I do have this working, but if I look at the settings in WHM > PHP Configuration Editor it is actually showing the user directive values, and if I make any changes here it will use those values, commenting out the user values.

Example
- Added user directive register_globals = ON and this successfully applies to the single account
- View WHM PHP Configuration Editor and it will show register_globals is ON (when its actually off)
- Save in WHM PHP Configuration Editor will overwrite global value switching register_globals ON
 

cPanelTristan

Quality Assurance Analyst
Staff member
Oct 2, 2010
7,606
33
238
somewhere over the rainbow
cPanel Access Level
Root Administrator
Re: Methods to Increase Security on suPHP - Restricting who can use php.ini

Why are you using PHP Configuration Editor? If it successfully applies to the single account, then it is working. You would want to use phpinfo on the different accounts (one with a PATH directive and one without one set) to see the results. I do not ever suggest to anyone to use the WHM PHP Configuration Editor.
 

digiscape

Member
Oct 15, 2003
6
0
151
Re: Methods to Increase Security on suPHP - Restricting who can use php.ini

Why use cPanel at all :)

Thats fine just as long a people know, using this means you can no longer use WHM editor
 

cPanelTristan

Quality Assurance Analyst
Staff member
Oct 2, 2010
7,606
33
238
somewhere over the rainbow
cPanel Access Level
Root Administrator
Re: Methods to Increase Security on suPHP - Restricting who can use php.ini

Anytime you do a customization of this sort, it would be expected you are going to have to do things manually. Manually means in command line not using GUI tools. If you could use the WHM PHP Configuration Editor for any of this, it would have been noted in the guide. It can be a bit misleading to state that my guide doesn't work for any of the methods when it does actually work and what didn't work was an area I never even suggested using in the guide haha
 

nike.stars

Registered
Jul 29, 2008
3
0
51
Re: Methods to Increase Security on suPHP - Restricting who can use php.ini

does this guide also actually disable ini_set capability to use custom php.ini ?
 

cPanelTristan

Quality Assurance Analyst
Staff member
Oct 2, 2010
7,606
33
238
somewhere over the rainbow
cPanel Access Level
Root Administrator
Re: Methods to Increase Security on suPHP - Restricting who can use php.ini

To confirm, do you have ini_set in disable_functions in the global php.ini file?

Also, what PHP version are you using? If you set the /opt/suphp/etc/suphp.conf to not allow custom php.ini files under PHP 5.3 by uncommenting the phprc_paths, then you shouldn't be able to override that via another method. If you can, then suPHP itself is the issue for allowing that to occur.
 

discountnetz

Active Member
Jul 2, 2011
27
1
51
Re: Methods to Increase Security on suPHP - Restricting who can use php.ini

Hello :)

I use your instructions and register_globals post_max_size or with a user account work very well.

I have been trying to load various extensions specifically I try the memcache and memcached extension reload

[PATH = / home / username / public_html]
extension_dir = "/ usr/local/lib/php/extensions/no-debug-non-zts-20090626"
extension = "memcache.so"
extension = "memcached.so"

Unfortunately it does not work. To use is not generally possible extensions in [PATH = / home / username / public_html]?

Best Regards
Jan
 

cPanelTristan

Quality Assurance Analyst
Staff member
Oct 2, 2010
7,606
33
238
somewhere over the rainbow
cPanel Access Level
Root Administrator
Re: Methods to Increase Security on suPHP - Restricting who can use php.ini

Hello Jan,

The one issue I've heard reported is the one you are describing. You cannot set these custom extensions for those users, right. You'll either have to have a PHP module extension available for all users or not available to any users. They can't be set via PATH directive.

Thanks!
 

goodmove

Well-Known Member
May 12, 2003
628
1
168
Re: Methods to Increase Security on suPHP - Restricting who can use php.ini

What type of permissions and ownership should a php.ini file in user's space (in /home/user) have?
 

cPanelTristan

Quality Assurance Analyst
Staff member
Oct 2, 2010
7,606
33
238
somewhere over the rainbow
cPanel Access Level
Root Administrator
Re: Methods to Increase Security on suPHP - Restricting who can use php.ini

I'm uncertain this is related to the existing guide, since this appears to be a general question about php.ini settings. The ownership should be the username, so username:username while the permissions should be 644 like most files.
 

goodmove

Well-Known Member
May 12, 2003
628
1
168
Re: Methods to Increase Security on suPHP - Restricting who can use php.ini

I'm uncertain this is related to the existing guide, since this appears to be a general question about php.ini settings. The ownership should be the username, so username:username while the permissions should be 644 like most files.
It is related in the way that username:username will allow the user to modify the php.ini. This can be undesirable in some circumstances. If the admin wants to retain control over the contents of the config file in the user's space, the ownership should be set to root:username.
 

cPanelTristan

Quality Assurance Analyst
Staff member
Oct 2, 2010
7,606
33
238
somewhere over the rainbow
cPanel Access Level
Root Administrator
Re: Methods to Increase Security on suPHP - Restricting who can use php.ini

It is not related to only suPHP and is not applicable to this guide. This guide's specific purpose has to do with using the php.ini file itself by calling the directives. It doesn't have to do with hacking the php.ini file. Feel free to open up your own guide on other security mechanisms for all PHP handlers.
 

copernic2006

Member
Dec 7, 2010
8
0
51
Re: Methods to Increase Security on suPHP - Restricting who can use php.ini

Hello,
In php.ini, I disabled fsockopen and I would activate only a few accounts, so I followed the proposed solution as follows:

[PATH=/home/username/public_html]
fsockopen = On
Unfortunately, this solution is not working, any help is welcome? :)

For information:
PHP: 5.3.17
Apache: 2.2.23
 
Last edited:

Astral God

Well-Known Member
Sep 27, 2010
180
0
66
127.0.0.1
cPanel Access Level
Root Administrator
Re: Methods to Increase Security on suPHP - Restricting who can use php.ini

The php.ini file under suPHP

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.
Hi.

I've tried this, but, this is not applied to ONE account but GLOBALLY - even in PHP Configuration Editor on WHM these "new" values are updated. :confused:

I'm using PHP 5.3.18.

Thanks.
 

borgia

Member
Jun 27, 2012
12
0
1
cPanel Access Level
Root Administrator
Re: Methods to Increase Security on suPHP - Restricting who can use php.ini

If I understand well you need php.ini by user no? This thing can be easy using Apache templates and hooks. Like this you can use php.ini for each account. So you can disable "fsockopen" for one particular account and the rest to be enable. If this is what you want let me know I'll explain.