Skip to main content

How to use SuPHP Custom INI files

ItsMattSon
Hi cPanel and all, I've read a bunch of threads on this and I've done my best reading through the cPanel Documentation but I'm afraid I'm not sure of the correct approach, so i'm chasing clarification please. If not DSO, open_basedir tweak is no use, right? Well, since I want to enforce that still, using the SuPHP handler of course, I understand that I'll need to use custom php.ini files per user (right?) So, I guess I have a few questions.
    ]
  • Where are the individual php.ini files *supposed* to be stored?
  • Users can edit these to their liking, right? And they can override the settings in the global php.ini?
  • What happens if a user does not have a php.ini? Does it default to the global?
  • Where should SuPHP_ConfigPath be set? In a .htaccess in each users' web root or somewhere where they can't mess with it? (preferable)
  • What if i didn't want them messing with their php.ini either? (because I rather they didn't, i'm only doing this so they can't break out of their home folder and into someone elses)
Some of these questions are half answered elsewhere, but not with enough certainty to answer them for me. If anyone knows the answers, I'd be grateful. Would love some kind of instruction on how to implement what I'm after (since I'm thinking a lot of WHM newbies probably don't realise they need to jail people themselves with SuPHP, despite the notice that open_basedir doesn't work with it) but I obviously don't expect it. I'll be happy with whatever I get. Thanks

Comments

8 comments

Date Votes
  • martin MHC
    I can answer some of these details, however I have issues with local PHP.ini files on WHM 60 accounts, 1) in the folder that is being accessed, for instace if your visitor is in example.com/somewhere/index.php then it will use the php.ini file in /public_html/somewhere/php.ini . It is good with .htaccess to deny browser access to php.ini. 2) Account users can yes. If they have access to the account file system. 3) yes, defaults to the global values. 4) I have found that suPHP ConfigPath breaks php.ini files when used for CPanel/WHM > v56. 5) I don't think PHP.ini files will cover people breaking out of their accounts. Accounts by default are jailed and the ini file alone can't change that. If you're allowing your account holders to upload PHP files they choose to the server, that's a very slippery slope towards danger. I do not think (but am not certain) PHP.ini can help any PHP file break out of it's jailed account.
    0
  • cPanelMichael
    Hello, Here's a copy of the response I recently sent on the EA4 php.ini/local.ini behavior thread: Hello, Here's a quick overview of how this works for anyone else visiting this thread. I'll use PHP 7 in this example, but the same behavior applies to any PHP version in EasyApache 4. 1. By default, no local.ini exists within the /opt/cpanel/ea-php70/root/etc/php.d/ directory. 2. I browse to "WHM Home " Software " MultiPHP INI Editor " Basic Mode ", choose ea-php70, and make a change to a PHP directive (let's say enabling allow_url_fopen). 3. Once I save the changes, /opt/cpanel/ea-php70/root/etc/php.d/local.ini is created and includes this change:
    # grep allow_url_fopen /opt/cpanel/ea-php70/root/etc/php.d/local.ini allow_url_fopen = On
    4. Assuming suPHP is configured as the PHP handler for PHP 7, and no local php.ini files exist under the account, allow_url_fopen correctly shows "On" in a PHPINFO file under a test account. 5. I then create a copy of /opt/cpanel/ea-php70/root/etc/php.ini with allow_url_fopen set to "Off" to /home/$user/public_html/php.ini. 6. When refreshing the PHPINFO page for the account, allow_url_fopen is still set to "On", despite the local php.ini file's setting. This is by design. If I want this option "Off", I must add the following line to the account's .htaccess file:
    suPHP_ConfigPath /home/$user/public_html/php.ini
    Once I do this, the option then reflects the value defined in the account's php.ini file. Here's the link to the document that explains how this works: The cPanel PHPRC PHP Patch for EasyApache 4 - EasyApache 4 - cPanel Documentation Thank you.
    In addition, here's a thread that explains how to prevent users from overriding php.ini values in suPHP on EA4: How To Disable Custom PHP.INI in Easyapache 4 Thank you.
    0
  • ItsMattSon
    Thanks guys! @cPanelMichael, I've locked everyone to the global php.ini now but the reason I asked this question initially was actually all about how I can jail people since open_basedir tweak doesn't work with SuPHP and I thought this was the solution haha. I know you can achieve what the "open_basedir tweak" does for DSO, with SuPHP, i just don't know how. That's where I'm stuck :P PHP open_basedir Tweak - Documentation - cPanel Documentation
    0
  • cPanelMichael
    Hello, You may find this thread helpful: suPHP, suExec and open_basedir oh my! Thank you.
    0
  • ItsMattSon
    Thanks @cPanelMichael. Seems that thread suggests largely to ensure important documents in public_html have strict permissions which is great however it doesn't stop me using an PHP include() to echo sensitive config files above /home, which is my main concern. Don't suppose you'd know the quick, easy way to go about implementing this solution? I get the concept, I don't get how to put it in place :(
    0
  • ItsMattSon
    While following cPanelTristan's guide to forcing the use of the global ini and adding lines to the bottom of the global ini per user, it seems to have locked me into my own home directory now which is good, but i have two concerns... Did I do it right? [PATH=/home/username/public_html] open_basedir = "/home/username" And second, I have still enabled (Home >> Security Center >> PHP open_basedir Tweak), but do I need to? I feel that if I don't, I miss out on the protection afforded by this below? open_basedir directives When you enable the open_basedir tweak, the system adds PHP directives to each Virtual Host in the httpd.conf file. These directives limit users' PHP access to the following directories: /usr/lib/php /usr/local/lib/php /tmp
    0
  • cPanelMichael
    Don't suppose you'd know the quick, easy way to go about implementing this solution? I get the concept, I don't get how to put it in place

    Are you referring to the automatic creation of php.ini files when the account is created? If so, the hooks documentation is a good place to start: Guide to Standardized Hooks - Software Development Kit - cPanel Documentation Guide to Standardized Hooks - Whostmgr Functions - Software Development Kit - cPanel Documentation
    And second, I have still enabled (Home >> Security Center >> PHP open_basedir Tweak), but do I need to? I feel that if I don't, I miss out on the protection afforded by this below? open_basedir directives When you enable the open_basedir tweak, the system adds PHP directives to each Virtual Host in the httpd.conf file. These directives limit users' PHP access to the following directories: /usr/lib/php /usr/local/lib/php /tmp

    You can enable the feature so that the functionality begins working right away in the event the PHP handler is configured to DSO in the future. However, you won't receive any benefit from enabling the feature if you aren't using DSO.
    While following cPanelTristan's guide to forcing the use of the global ini and adding lines to the bottom of the global ini per user, it seems to have locked me into my own home directory now which is good, but i have two concerns... Did I do it right? [PATH=/home/username/public_html] open_basedir = "/home/username"

    That looks correct, however, you may want to apply it to "/home/username" and set the entry to something like this: open_basedir = "/home/username:/usr/lib/php:/usr/local/lib/php:/tmp" Thank you.
    0
  • ItsMattSon
    That looks correct, however, you may want to apply it to "/home/username" and set the entry to something like this: open_basedir = "/home/username:/usr/lib/php:/usr/local/lib/php:/tmp"

    Ah, that's what I was after! :) Just didn't know how to include those so I'm all sorted on this thread now. Thanks again, Michael!
    0

Please sign in to leave a comment.

Didn't find what you were looking for?

New post