How to configure SuPHP to use only the MultiPHP INI file, not user inis, and open_basedir?
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
- Go to Software > MultiPHP Manager > PHP Handlers. Select Edit on ea-php70, choose suphp and click Apply.
- 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/
- 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"
- Comment out original open_basedir line.
-
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 0 -
How to disable custom user.ini files in public_html for Easyapache 4 - Bobcares is this you are looking at? 0 -
Hello Matt, First, it's important to note the following information that we provide on our PHPRC environmental variable. Unexpected behavior may occur.
[QUOTE]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 DocumentationBonus 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.0 -
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 0 -
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: Thank you.0 -
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? :) 0 -
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.0 -
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? 0 -
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: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" php_admin_value open_basedir "/home/accountusername:/usr/lib/php:/usr/php4/lib/php:/usr/local/lib/php:/usr/local/php4/lib/php:/tmp" php_admin_value open_basedir "/home/accountusername:/usr/lib/php:/usr/local/lib/php:/tmp" php_admin_value open_basedir "/home/accountusername:/usr/lib/php:/usr/php4/lib/php:/usr/local/lib/php:/usr/local/php4/lib/php:/tmp"
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.0 -
Hi Matt, Enabling the "PHP open_basedir Tweak" in WHM adds the following entries to each Virtual Host in Apache configuration file:
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" php_admin_value open_basedir "/home/accountusername:/usr/lib/php:/usr/php4/lib/php:/usr/local/lib/php:/usr/local/php4/lib/php:/tmp" php_admin_value open_basedir "/home/accountusername:/usr/lib/php:/usr/local/lib/php:/tmp" php_admin_value open_basedir "/home/accountusername:/usr/lib/php:/usr/php4/lib/php:/usr/local/lib/php:/usr/local/php4/lib/php:/tmp"
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 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"0 -
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? 0 -
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.0 -
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! 0 -
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? 0 -
Hello Matt, The following post includes an example of how to add a custom PHP configuration value for an individual account utilizing PHP-FPM: 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: 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. 0 -
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. 0 -
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.0 -
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: - Followed the steps in the
- Checked phpinfo and the open_basedir directive has been reflected, with correct PHP version.
0 - Followed the steps in the
-
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 dochattr +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? [COLOR=rgb(0, 0, 0)]0 -
Hello @bgarrant, Yes, those values look to match what's referenced earlier in this thread. 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?
Each user requires their own custom open_basedir vaues in their PHP configuration files when you select a PHP handler that is not DSO. Setting a global open_basedir value for suPHP isn't supported at this time.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?
Using chattr to prevent modifications to a file is not something we recommend. Additionally, we recommend using the INI Editor in cPanel to make these types of changes as this ensures the proper entries/files are automatically populated in the event the handler changes in the future. There's not currently a supported method to prevent user modifications to individual PHP configuration files with suPHP, aside from the workarounds referenced in this post:0 -
Hello @bgarrant, Yes, those values look to match what's referenced earlier in this thread.
Hello @bgarrant, Yes, those values look to match what's referenced earlier in this thread. Each user requires their own custom open_basedir vaues in their PHP configuration files when you select a PHP handler that is not DSO. Setting a global open_basedir value for suPHP isn't supported at this time. Using chattr to prevent modifications to a file is not something we recommend. Additionally, we recommend using the INI Editor in cPanel to make these types of changes as this ensures the proper entries/files are automatically populated in the event the handler changes in the future. There's not currently a supported method to prevent user modifications to individual PHP configuration files with suPHP, aside from the workarounds referenced in this post: Thank you.
@cPanelMichael Couple questions then I am all set I think. So if I want to add an open_basedir entry for each domain, should I add it to the home directory or the domain location (public_html). I prefer to have it above webroot if we can, but that did not seem to work using the Multi editor. Please advise. Since no users have a php.ini file yet, do I need to add a basic one first, then the entry in the Editor view for open_basedir? Would user.ini be preferred? Also, I noticed the PHP.ini created does not match the .user.ini when you add with Editir view. Do I need to copy over open_basedir line? Lastly, how do I make the open_basedir to work global for the domain? It does not seem to work in subfolders or anywhere else other than its own folder? Do I need to comment out open_basedir in the Global server php71 PHP.ini i assume? Thanks in advance0 -
So if I want to add an open_basedir entry for each domain, should I add it to the home directory or the domain location (public_html). I prefer to have it above webroot if we can, but that did not seem to work using the Multi editor. Please advise.
The default entry, and the one I used when testing earlier in the thread, was "/home/username/".Since no users have a php.ini file yet, do I need to add a basic one first, then the entry in the Editor view for open_basedir? Would user.ini be preferred?
No, the MultiPHP INI Editor feature will take care of all of that for you. There's no need to manually modify or create any files.Also, I noticed the PHP.ini created does not match the .user.ini when you add with Editir view. Do I need to copy over open_basedir line?
No manual modifications are required. The INI Editor in cPanel should automatically populate the required files with the correct entries.Lastly, how do I make the open_basedir to work global for the domain? It does not seem to work in subfolders or anywhere else other than its own folder? Do I need to comment out open_basedir in the Global server php71 PHP.ini i assume?
Adding a global value isn't supported with suPHP, so you should remove the global entry to verify if that's the reason it's not working. Thank you.0 -
The default entry, and the one I used when testing earlier in the thread, was "/home/username/". No, the MultiPHP INI Editor feature will take care of all of that for you. There's no need to manually modify or create any files. No manual modifications are required. The INI Editor in cPanel should automatically populate the required files with the correct entries. Adding a global value isn't supported with suPHP, so you should remove the global entry to verify if that's the reason it's not working. Thank you.
@cPanelMichael I created it exactly as you said, but the files in public_html are not seeing the new php.ini, .user.ini or .htaccess files in the "/home/user" directory. What is missing? here is what it created: /home/perufcu/php.ini; cPanel-generated php ini directives, do not edit ; Manual editing of this file may result in unexpected behavior. ; To make changes to this file, use the cPanel MultiPHP INI Editor (Home >> Software >> MultiPHP INI Editor) ; For more information, read our documentation (https://go.cpanel.net/EA4ModifyINI) open_basedir = "/home/perufcu:/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" allow_url_fopen = Off allow_url_include = Off display_errors = Off enable_dl = Off file_uploads = On max_execution_time = 90 max_input_time = 120 max_input_vars = 1000 memory_limit = 512M post_max_size = 16M session.gc_maxlifetime = 1440 session.save_path = "/var/cpanel/php/sessions/ea-php71" upload_max_filesize = 16M zlib.output_compression = Off
/home/perufcu/.user.ini; cPanel-generated php ini directives, do not edit ; Manual editing of this file may result in unexpected behavior. ; To make changes to this file, use the cPanel MultiPHP INI Editor (Home >> Software >> MultiPHP INI Editor) ; For more information, read our documentation (https://go.cpanel.net/EA4ModifyINI) [PHP] display_errors = Off max_execution_time = 90 max_input_time = 120 max_input_vars = 1000 memory_limit = 512M post_max_size = 16M session.gc_maxlifetime = 1440 session.save_path = "/var/cpanel/php/sessions/ea-php71" upload_max_filesize = 16M zlib.output_compression = Off
/home/perufcu/.htaccess# BEGIN cPanel-generated php ini directives, do not edit # Manual editing of this file may result in unexpected behavior. # To make changes to this file, use the cPanel MultiPHP INI Editor (Home >> Software >> MultiPHP INI Editor) # For more information, read our documentation (https://go.cpanel.net/EA4ModifyINI) php_flag display_errors Off php_value max_execution_time 90 php_value max_input_time 120 php_value max_input_vars 1000 php_value memory_limit 512M php_value post_max_size 16M php_value session.gc_maxlifetime 1440 php_value session.save_path "/var/cpanel/php/sessions/ea-php71" php_value upload_max_filesize 16M php_flag zlib.output_compression Off # END cPanel-generated php ini directives, do not edit
phpinfo() to look and you see it is not loading correct ini file and open_basedir is missing.0 -
phpinfo() to look and you see it is not loading correct ini file and open_basedir is missing.
To clarify, are you using suPHP as the handler for the version of PHP assigned to the account, and is PHP-FPM disabled for this account when checking from "WHM >> MultiPHP Manager"? Thank you.0 -
To clarify, are you using suPHP as the handler for the version of PHP assigned to the account, and is PHP-FPM disabled for this account when checking from "WHM >> MultiPHP Manager"? Thank you.
@cPanelMichael That is correct. suPHP and PHP-FPM is disabled0 -
To clarify, are you using suPHP as the handler for the version of PHP assigned to the account, and is PHP-FPM disabled for this account when checking from "WHM >> MultiPHP Manager"? Thank you.
@cPanelMichael It is like the folders in public_html and below are not seeing the INI files above the webroot. There is no php.ini or .user.ini in the public_html folder. There is a .htaccess file in the /public_html folder which came from the Statamic CMS, but it does not look like that would affect anything at all. I tested even without the public_html/.htaccess it and the PHP info page still won't see the newly added ini files0 -
To clarify, are you using suPHP as the handler for the version of PHP assigned to the account, and is PHP-FPM disabled for this account when checking from "WHM >> MultiPHP Manager"? Thank you.
something is definitely wrong. The only thing that works in manually creating a .user.ini file, placing it in "home/user" directory. The content of the file are:open_basedir = "/home/perufcu:/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"
Can a .user.ini be placed in the Home Directory like this (/home/perufcu/.user.ini)? I normally see them in public_html folders but is it OK? It seems to add the open_basedir and is recursive. q0 -
To clarify, are you using suPHP as the handler for the version of PHP assigned to the account, and is PHP-FPM disabled for this account when checking from "WHM >> MultiPHP Manager"? Thank you.
@cPanelMichael I am wondering if I should update to version 70. I am on 68.0.36 and maybe that is the issue? What do you think?0 -
To clarify, are you using suPHP as the handler for the version of PHP assigned to the account, and is PHP-FPM disabled for this account when checking from "WHM >> MultiPHP Manager"? Thank you.
@cPanelMichael So from the docs it says that if suPHP is the handler I should have a custom PHP.ini created. Why is mine also creating a .user.ini and .htaccess files? For some reason when I create an ini using the tool in cPanel in the Home Directory my site will not use the new ini file. No idea why. It is supposed to. Should we open a ticket or upgrade to cPanel 70?0 -
To clarify, are you using suPHP as the handler for the version of PHP assigned to the account, and is PHP-FPM disabled for this account when checking from "WHM >> MultiPHP Manager"? Thank you.
@cPanelMichael I am all set Michael. James helped me with a support ticket.0
Please sign in to leave a comment.
Comments
30 comments