Please whitelist cPanel in your adblocker so that you’re able to see our version release promotions, thanks!

The Community Forums

Interact with an entire community of cPanel & WHM users!
  1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

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

Discussion in 'Security' started by ItsMattSon, Jan 31, 2018.

Tags:
  1. ItsMattSon

    ItsMattSon Well-Known Member

    Joined:
    Sep 5, 2016
    Messages:
    167
    Likes Received:
    34
    Trophy Points:
    28
    Location:
    Perth
    cPanel Access Level:
    Root Administrator
    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.
     
  2. ItsMattSon

    ItsMattSon Well-Known Member

    Joined:
    Sep 5, 2016
    Messages:
    167
    Likes Received:
    34
    Trophy Points:
    28
    Location:
    Perth
    cPanel Access Level:
    Root Administrator
    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
     
  3. sktest123

    sktest123 Well-Known Member

    Joined:
    Jan 31, 2017
    Messages:
    87
    Likes Received:
    5
    Trophy Points:
    8
    Location:
    kochin
    cPanel Access Level:
    Root Administrator
  4. cPanelMichael

    cPanelMichael Forums Analyst
    Staff Member

    Joined:
    Apr 11, 2011
    Messages:
    42,734
    Likes Received:
    1,706
    Trophy Points:
    363
    cPanel Access Level:
    Root Administrator
    Hello Matt,

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

    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

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

    Thank you.
     
    ItsMattSon likes this.
  5. ItsMattSon

    ItsMattSon Well-Known Member

    Joined:
    Sep 5, 2016
    Messages:
    167
    Likes Received:
    34
    Trophy Points:
    28
    Location:
    Perth
    cPanel Access Level:
    Root Administrator
    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
     
  6. cPanelMichael

    cPanelMichael Forums Analyst
    Staff Member

    Joined:
    Apr 11, 2011
    Messages:
    42,734
    Likes Received:
    1,706
    Trophy Points:
    363
    cPanel Access Level:
    Root Administrator
    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.
     
  7. ItsMattSon

    ItsMattSon Well-Known Member

    Joined:
    Sep 5, 2016
    Messages:
    167
    Likes Received:
    34
    Trophy Points:
    28
    Location:
    Perth
    cPanel Access Level:
    Root Administrator
    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? :)
     
  8. cPanelMichael

    cPanelMichael Forums Analyst
    Staff Member

    Joined:
    Apr 11, 2011
    Messages:
    42,734
    Likes Received:
    1,706
    Trophy Points:
    363
    cPanel Access Level:
    Root Administrator
    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:

    Code:
    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.
     
  9. ItsMattSon

    ItsMattSon Well-Known Member

    Joined:
    Sep 5, 2016
    Messages:
    167
    Likes Received:
    34
    Trophy Points:
    28
    Location:
    Perth
    cPanel Access Level:
    Root Administrator
    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?
     
  10. cPanelMichael

    cPanelMichael Forums Analyst
    Staff Member

    Joined:
    Apr 11, 2011
    Messages:
    42,734
    Likes Received:
    1,706
    Trophy Points:
    363
    cPanel Access Level:
    Root Administrator
    Hi Matt,

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

    Code:
      <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.
     
    ItsMattSon likes this.
  11. ItsMattSon

    ItsMattSon Well-Known Member

    Joined:
    Sep 5, 2016
    Messages:
    167
    Likes Received:
    34
    Trophy Points:
    28
    Location:
    Perth
    cPanel Access Level:
    Root Administrator
    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"
     
    cPanelMichael likes this.
  12. ItsMattSon

    ItsMattSon Well-Known Member

    Joined:
    Sep 5, 2016
    Messages:
    167
    Likes Received:
    34
    Trophy Points:
    28
    Location:
    Perth
    cPanel Access Level:
    Root Administrator
    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?
     
  13. cPanelMichael

    cPanelMichael Forums Analyst
    Staff Member

    Joined:
    Apr 11, 2011
    Messages:
    42,734
    Likes Received:
    1,706
    Trophy Points:
    363
    cPanel Access Level:
    Root Administrator
    Hello,

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

    Code:
    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.
     
  14. ItsMattSon

    ItsMattSon Well-Known Member

    Joined:
    Sep 5, 2016
    Messages:
    167
    Likes Received:
    34
    Trophy Points:
    28
    Location:
    Perth
    cPanel Access Level:
    Root Administrator
    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!
     
    #14 ItsMattSon, Feb 20, 2018
    Last edited: Feb 20, 2018
  15. ItsMattSon

    ItsMattSon Well-Known Member

    Joined:
    Sep 5, 2016
    Messages:
    167
    Likes Received:
    34
    Trophy Points:
    28
    Location:
    Perth
    cPanel Access Level:
    Root Administrator
    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?
     
  16. cPanelMichael

    cPanelMichael Forums Analyst
    Staff Member

    Joined:
    Apr 11, 2011
    Messages:
    42,734
    Likes Received:
    1,706
    Trophy Points:
    363
    cPanel Access Level:
    Root Administrator
    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.
     
  17. ItsMattSon

    ItsMattSon Well-Known Member

    Joined:
    Sep 5, 2016
    Messages:
    167
    Likes Received:
    34
    Trophy Points:
    28
    Location:
    Perth
    cPanel Access Level:
    Root Administrator
    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.
     
  18. cPanelMichael

    cPanelMichael Forums Analyst
    Staff Member

    Joined:
    Apr 11, 2011
    Messages:
    42,734
    Likes Received:
    1,706
    Trophy Points:
    363
    cPanel Access Level:
    Root Administrator
    The changes are preserved through updates.

    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.

    Thank you.
     
    ItsMattSon likes this.
  19. ItsMattSon

    ItsMattSon Well-Known Member

    Joined:
    Sep 5, 2016
    Messages:
    167
    Likes Received:
    34
    Trophy Points:
    28
    Location:
    Perth
    cPanel Access Level:
    Root Administrator
    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:
      Code:
      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 :)
     
    cPanelMichael likes this.
  20. bgarrant

    bgarrant Well-Known Member

    Joined:
    Jun 27, 2012
    Messages:
    65
    Likes Received:
    9
    Trophy Points:
    8
    cPanel Access Level:
    Root Administrator
    @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:

    Code:
    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
    Code:
    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?



     

    Attached Files:

Loading...

Share This Page