How to configure SuPHP to use only the MultiPHP INI file, not user inis, and open_basedir?

[ItsMattSon]

Hi cPanel team,

I wrote out some steps in the past on how to configure SuPHP to use only the MultiPHP INI file and to set the open_basedir for users on the system. However, I noticed that phpinfo() doesn't seem to mention the php ini in /usr/local/lib which I'm apparently "forcing the handler to use" so that's obviously not working.

In addition to that not working, I noticed that php ini isn't the one in MultiPHP INI anyway so that's not too troubling but I do want to "enforce" all accounts to use the MultiPHP INI and not have the ability to use *anything* else, even user inis.

Can someone tell me how to configure SuPHP to only use the MultiPHP INI file and none others, especially not user inis per account?

I'm also very confused whether I've configured the open_basedir entries correctly too. Is that accurate or have i done a bad job of that? (is there a better way?)

(Steps I've been using up to now that don't work)
Configure SuPHP and open_basedir Protection

1. Go to Software > MultiPHP Manager > PHP Handlers. Select Edit on ea-php70, choose suphp and click Apply.
   
2. Due to SuPHP allowing individual php.ini files, restrict all accounts to the global php.ini file. Uncomment the following lines in /opt/suphp/etc/suphp.conf
   [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/
3. Go to Software > MultiPHP INI Editor. Change to Editor Mode tab and select ea-php70. Add the following to the bottom of the config.
   [PATH=/home/myacc1]
   open_basedir = "/home/myacc1:/usr/lib/php:/usr/local/lib/php:/tmp"
   [PATH=/home/myacc2]
   open_basedir = "/home/myacc2:/usr/lib/php:/usr/local/lib/php:/tmp"
   [PATH=/home/myacc3]
   open_basedir = "/home/myacc3:/usr/lib/php:/usr/local/lib/php:/tmp"
   [PATH=/home/myacc4]
   open_basedir = "/home/myacc4:/usr/lib/php:/usr/local/lib/php:/tmp"
   
4. Comment out original open_basedir line.

 

[ItsMattSon]

To re-word my problem, I want to lock down SuPHP to use only the MultiPHP INI file and not allow individual INI files (including .user.ini). Is this possible?

Bonus points if you can give me a real world example why I shouldn't lock it down :P

 

[sktest123]

How to disable custom user.ini files in public_html for Easyapache 4 - Bobcares
is this you are looking at?

 

[cPanelMichael]

Hello Matt,

First, it's important to note the following information that we provide on our PHP Handlers document:

The suphp.conf file warnings

• We strongly recommend that you allow your system to load the .ini files and directives as it finds them. This guarantees the most predictable results.

• We strongly recommend that you do not set the [phprc_paths] section, the suPHP_ConfigPath directive or set the PHPRC environmental variable. Unexpected behavior may occur.

The suphp.conf file includes the [phprc_paths] section. You can use this section to lock a particular PHP handler to its default php.ini file, but we strongly recommend against this usage.

If you do prefer to force a specific a specific INI file for each PHP version, we document the PHPRC PHP Patch for EasyApache 4 in more detail at:

The cPanel PHPRC PHP Patch for EasyApache 4 - EasyApache 4 - cPanel Documentation

Bonus points if you can give me a real world example why I shouldn't lock it down :P

Is there a particular problem you are attempting to address by preventing users from modifying their PHP configuration values?

Thank you.

 

[ItsMattSon]

Hi @cPanelMichael,

I was merely hoping to lock it down to avoid potential for exploitation, but nothing in particular. With that said, you've talked me out of it haha. I won't proceed with that at all, I will leave it as it were out-of-the-box

With the INI stuff out of the way now, would you know how I can set the open_basedir for each user? (and where?). I'm using SuPHP as handler so the tweak in WHM doesn't do the trick.

Any guidance would, as always, be super appreciated! Thanks

 

[cPanelMichael]

With the INI stuff out of the way now, would you know how I can set the open_basedir for each user? (and where?). I'm using SuPHP as handler so the tweak in WHM doesn't do the trick.

Any guidance would, as always, be super appreciated! Thanks

Hi Matt,

You'd need to manually setup the open_basedir entry using the "Editor Mode" tab in "cPanel >> MultiPHP INI Editor" for each account due to an existing bug related to enabling PHP open_basedir in EasyApache 4. It's discussed at:

WHM66 and open_basedir issues with session.save_path

Thank you.

 

[ItsMattSon]

Hi @cPanelMichael

Thanks for the response.

I wonder, based on what I read in the thread you cited, would this be correct for what to set open_basedir to then?

open_basedir = "/home/myacc1/public_html:/usr/lib/php:/usr/local/lib/php:/var/cpanel/php/sessions"

Note: I took /tmp out because you stated it was no longer required, and that sessions folder was added because it appears that it is required now according to the thread.

Can you tell me if that looks like a suitable open_basedir to use in cPanel before I set it?

 

[cPanelMichael]

Hi Matt,

You'd need to adjust the paths to match the specific version of PHP assigned to the account. For example, with PHP 5.6:

open_basedir "/home/myacc1:/opt/cpanel/ea-php56/root/usr/bin/php:/usr/local/bin/ea-php56:/usr/bin/ea-php56:/var/cpanel/php/sessions/ea-php56"

Once internal case EA-5664 is solved, you'd need to remove the custom entries because at that point the system should automatically populate the entries to account for actions such as changes to the account's PHP version.

Thank you.

 

[ItsMattSon]

Hi @cPanelMichael

Sorry to be a pain, but what does the "open_basedir Tweak" set for DSO? Is it what you put above?

Wouldn't I just need to set the same open_basedir directive as what the tweak sets, but per account in cPanel fo suPHP?

 

[cPanelMichael]

Hi Matt,

what does the "open_basedir Tweak" set for DSO? Is it what you put above?

Enabling the "PHP open_basedir Tweak" in WHM adds the following entries to each Virtual Host in Apache configuration file:

  <IfModule concurrent_php.c>

    php4_admin_value open_basedir "/home/accountusername:/usr/lib/php:/usr/php4/lib/php:/usr/local/lib/php:/usr/local/php4/lib/php:/tmp"

    php5_admin_value open_basedir "/home/accountusername:/usr/lib/php:/usr/local/lib/php:/tmp"

  </IfModule>

  <IfModule !concurrent_php.c>

    <IfModule mod_php4.c>

      php_admin_value open_basedir "/home/accountusername:/usr/lib/php:/usr/php4/lib/php:/usr/local/lib/php:/usr/local/php4/lib/php:/tmp"

    </IfModule>

    <IfModule mod_php5.c>

      php_admin_value open_basedir "/home/accountusername:/usr/lib/php:/usr/local/lib/php:/tmp"

    </IfModule>

    <IfModule sapi_apache2.c>

      php_admin_value open_basedir "/home/accountusername:/usr/lib/php:/usr/php4/lib/php:/usr/local/lib/php:/usr/local/php4/lib/php:/tmp"

    </IfModule>

This happens no matter which PHP handler is installed or enabled on the accounts, but it's only intended to enable the feature for accounts that utilize DSO as the PHP handler (it's added for all accounts in-case the handler for those accounts is later switched to DSO). Additionally, as you can see in the code above, those entries do not account for the changes to the PHP paths with EasyApache 4 (that's part of the bug report). Thus for now, even if you use DSO, you'd still need to utilize custom entries (using a custom virtualhost include instead of a custom php.ini modification).

Wouldn't I just need to set the same open_basedir directive as what the tweak sets, but per account in cPanel fo suPHP?

Generally, the answer to that question is yes. However, part of the issue reported as part of internal case EA-5664 is that the PHP open_basedir Tweak is still utilizing the same entries that it did with EasyApache 3. Those entries are no longer valid since the PHP paths have changed in EasyApache 4, thus when editing the PHP configuration files for each account that uses suPHP, you have to use an entry like the one referenced in my last response.

Also, it's no trouble at all to help answer these types of questions. That's what we are here for!

Thank you.

 

[ItsMattSon]

Hi Matt,



Enabling the "PHP open_basedir Tweak" in WHM adds the following entries to each Virtual Host in Apache configuration file:

  <IfModule concurrent_php.c>

    php4_admin_value open_basedir "/home/accountusername:/usr/lib/php:/usr/php4/lib/php:/usr/local/lib/php:/usr/local/php4/lib/php:/tmp"

    php5_admin_value open_basedir "/home/accountusername:/usr/lib/php:/usr/local/lib/php:/tmp"

  </IfModule>

  <IfModule !concurrent_php.c>

    <IfModule mod_php4.c>

      php_admin_value open_basedir "/home/accountusername:/usr/lib/php:/usr/php4/lib/php:/usr/local/lib/php:/usr/local/php4/lib/php:/tmp"

    </IfModule>

    <IfModule mod_php5.c>

      php_admin_value open_basedir "/home/accountusername:/usr/lib/php:/usr/local/lib/php:/tmp"

    </IfModule>

    <IfModule sapi_apache2.c>

      php_admin_value open_basedir "/home/accountusername:/usr/lib/php:/usr/php4/lib/php:/usr/local/lib/php:/usr/local/php4/lib/php:/tmp"

    </IfModule>

This happens no matter which PHP handler is installed or enabled on the accounts, but it's only intended to enable the feature for accounts that utilize DSO as the PHP handler (it's added for all accounts in-case the handler for those accounts is later switched to DSO). Additionally, as you can see in the code above, those entries do not account for the changes to the PHP paths with EasyApache 4 (that's part of the bug report). Thus for now, even if you use DSO, you'd still need to utilize custom entries (using a custom virtualhost include instead of a custom php.ini modification).



Generally, the answer to that question is yes. However, part of the issue reported as part of internal case EA-5664 is that the PHP open_basedir Tweak is still utilizing the same entries that it did with EasyApache 3. Those entries are no longer valid since the PHP paths have changed in EasyApache 4, thus when editing the PHP configuration files for each account that uses suPHP, you have to use an entry like the one referenced in my last response.

Also, it's no trouble at all to help answer these types of questions. That's what we are here for!

Thank you.

Fantastic - Thanks cPanelMichael! I think I understand now

I've used your suggestion for my open_basedir directive for each cPanel, but with the addition of the share/pear directory as per SOLVED - Something went wrong while saving this configuration: Validate class not found from basename to overcome an include_path expectation so that Magento 2 works.

This is what I used:
open_basedir = "/home/myacc1:/opt/cpanel/ea-php70/root/usr/bin/php:/usr/local/bin/ea-php70:/usr/bin/ea-php70:/var/cpanel/php/sessions/ea-php70:/opt/cpanel/ea-php70/root/usr/share/pear"

 

[ItsMattSon]

Hi @cPanelMichael

Looks like I celebrated too soon! My gut made me wonder if it was actually taking effect so I checked in phpinfo and its set to 'no value' in Local and Master value. Uh oh

Would you know why that might be?

 

[cPanelMichael]

Hello,

Here's the specific entry I used under "Editor Mode" in "cPanel >> MultiPHP INI Editor" when testing this on an account using suPHP:

open_basedir = "/home/username/:/opt/cpanel/ea-php56/root/usr/bin/php:/usr/local/bin/ea-php56:/usr/bin/ea-php56:/var/cpanel/php/sessions/ea-php56"

This is correctly reflected in the PHPINFO file opened in a web browser. Are you sure suPHP is enabled as the default handler for the version of PHP associated with this account? Did you revert any previous changes you made to restrict php.ini access with suPHP?

Thank you.

 

[ItsMattSon]

Hi @cPanelMichael,

Silly me, I was choosing "Home Directory" instead of "domainname.com" in the cPanel > MultiPHP INI Editor > Editor Mode and editing that. It clearly states not to edit it, but I totally didn't notice haha.

Home Directory modifies /home/username/php.ini
domainname.com modifies /home/username/public_html/php.ini

Works great now I'm editing the right file. Thanks Michael!

 

[ItsMattSon]

Jumped the gun again, darn it! Just realised that doing the same in the domain that uses PHP-FPM doesn't show the open_basedir in phpinfo that I just set in cPanel in the same way as the SuPHP domain.

I just changed domain from PHP-FPM to No and the open_basedir shows the value from /home/username/public_html/php.ini that I set via cPanel > MultiPHP INI Editor, but changing it back to Yes (to use PHP-FPM) ignore that file it seems?

Thoughts on that, Mike?
Now SuPHP has been answered, how to set open_basedir for PHP-FPM now? >_>

Also, are you sure that /tmp shouldn't be in the open_basedir too?

 

[cPanelMichael]

Hello Matt,

The following post includes an example of how to add a custom PHP configuration value for an individual account utilizing PHP-FPM:

PHP-FPM configuration settings

As far as the /tmp directory, PHP session files are no longer stored in /tmp as of cPanel version 64. This is documented under the "session.save_path" section at:

MultiPHP INI Editor for WHM - Version 70 Documentation - cPanel Documentation

That said, if your PHP scripts make use of the /tmp directory in some other way, then you may need to include it as part of the allowed paths in your open_basedir entry.

Thank you.

 

[ItsMattSon]

Thanks @cPanelMichael

Just before I do that though, will cPanel/WHM updates undo this at any point?

Is there a plan for PHP-FPM settings to be changed within WHM? Is a shame that it looked like the INI editor was the right way to set PHP directives, it would be good if it was clear that the INI editor is of no use to domains using PHP-FPM.

 

[cPanelMichael]

Just before I do that though, will cPanel/WHM updates undo this at any point?

The changes are preserved through updates.

Is there a plan for PHP-FPM settings to be changed within WHM? Is a shame that it looked like the INI editor was the right way to set PHP directives, it would be good if it was clear that the INI editor is of no use to domains using PHP-FPM.

We do have an internal case open (CPANEL-11563) to address the issue where changes made in "cPanel >> MultiPHP INI Editor" are not reflected when PHP-FPM is enabled for the domain name. However, there's currently no time frame on the publication of a resolution.

Update: The decision on case CPANEL-11563 was to inform the user about the unavailability of PHP-FPM settings in the cPanel >> MultiPHP INI Editor interface.

Thank you.

 

[ItsMattSon]

Thanks @cPanelMichael

I've followed the general instructions and I'm happy with the result now. It's not optimal right now but one day I think it could be once the MultiPHP INI Editor changes affect PHP-FPM config too (and not get overridden) which you said an internal case for so that's awesome.

Just in case anyone has been following this thread, it got a bit confusing in the middle there because I asked how to configure SuPHP when really it was PHP-FPM I was trying to configure (sorry about that) but nonetheless here is what I did:

1. Followed the steps in the thread I was linked
2. Created and edited the PHP-FPM global YAML config file at /var/cpanel/ApachePHPFPM/system_pool_defaults.yaml, adding:
   

   php_value_open_basedir: { name: 'php_value[open_basedir]', value: "[% documentroot %]:/opt/cpanel/[% ea_php_version %]/root/usr/bin/php:/usr/local/bin/[% ea_php_version %]:/usr/bin/[% ea_php_version %]:/var/cpanel/php/sessions/[% ea_php_version %]:/opt/cpanel/[% ea_php_version %]/root/usr/share/pear" }

3. Checked phpinfo and the open_basedir directive has been reflected, with correct PHP version.

Thanks for the help, Mike. I don't think I would've realised the MultiPHP INI Editor wasn't supposed to config PHP-FPM without you enlightening me. I just thought my installation was broken.

Appreciate the help. I'm sorted now

 

[bgarrant]

Hello,

Here's the specific entry I used under "Editor Mode" in "cPanel >> MultiPHP INI Editor" when testing this on an account using suPHP:

open_basedir = "/home/username/:/opt/cpanel/ea-php56/root/usr/bin/php:/usr/local/bin/ea-php56:/usr/bin/ea-php56:/var/cpanel/php/sessions/ea-php56"

This is correctly reflected in the PHPINFO file opened in a web browser. Are you sure suPHP is enabled as the default handler for the version of PHP associated with this account? Did you revert any previous changes you made to restrict php.ini access with suPHP?

Thank you.

@cPanelMichael

Hi Michael. I added a .user.ini into the "/home/user" directory as I wanted to make it global and hopefully prevent users from editing it. I am on cPanel version 68.0.36 Release Tier. All I have in the file is this:

open_basedir = "home/user:/usr/lib/php:/usr/local/lib/php:/tmp:/opt/cpanel/ea-php71/root/usr/bin/php:/usr/local/bin/ea-php71:/usr/bin/ea-php71:/var/cpanel/php/sessions/ea-php71

I noticed that you had some new paths in there coming in v70, so I added them now. Does this all look correct? It seems to show values correct (see screenshot).

Next, do I need to place an open_basedir value in the global php.ini file as you can see no value is set? If so, what should it be?

Also, how do I make this file so no user can modify it? A friend told me to do

chattr +I .user.ini

and it makes it so it can't be modified. Is that best way to handle that? What do you recommend as we do not want users to be able to change any overrides we have in the .user.ini file?