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 control who gets which php.ini

Discussion in 'Security' started by santrix, Feb 6, 2010.

  1. santrix

    santrix Well-Known Member

    Joined:
    Nov 30, 2008
    Messages:
    223
    Likes Received:
    2
    Trophy Points:
    18
    The goal:

    Lock everyone to the central php.ini file apart from a few users who I might trust a little more!

    My current situation:

    Running Apache 2.2, php 5.2.9 via suphp, Apache suEXEC on.

    /opt/suphp/etc/suphp.conf has been edited thus:

    [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/

    OK, now this works fine, but I would like to have the option of allowing trusted users to be able to use their own php.ini file, and the solution above appears to be an uber-godmode measure.

    Can anyone provide me with a reasonably comprehensive guide to setting up my server to allow the odd trusted user to be able to use his own php.ini files?
     
  2. WebHostDog

    WebHostDog Well-Known Member

    Joined:
    Sep 3, 2006
    Messages:
    144
    Likes Received:
    0
    Trophy Points:
    16
    cPanel Access Level:
    Website Owner
  3. santrix

    santrix Well-Known Member

    Joined:
    Nov 30, 2008
    Messages:
    223
    Likes Received:
    2
    Trophy Points:
    18
  4. mtindor

    mtindor Well-Known Member

    Joined:
    Sep 14, 2004
    Messages:
    1,281
    Likes Received:
    37
    Trophy Points:
    48
    Location:
    inside a catfish
    cPanel Access Level:
    Root Administrator
    Let me caution about the procedure you mention for using the include system.

    Im running Apache 2.2.x and suPHP. If I simply add your code to /usr/local/apache/conf/includes/pre_main_global.conf and then rebuild httpd.conf using /scripts/ensure_vhost_includes --all-users , the expected changes do not take effect. If I stick a php.ini file in a user's public_html directory with "disable functions =" in it and then view phpinfo for that site, it will reveal:

    Loaded Configuration File: /home/username/public_html/php.ini

    and

    disable_functions =

    The only way I could get apache to force a global php.ini while allowing the admin the ability to provide a custom php.ini for certain users is to create a file inside /usr/local/apache/conf/userdata with the appropriate suPHP_ConfigPath directive.

    I created /usr/local/apache/conf/userdata/suphp_configpath.conf

    In that file I added:

    <IfModule mod_suphp.c>
    <Location />
    suPHP_ConfigPath /usr/local/lib/
    </Location>
    </IfModule>

    I then ran /scripts/ensure_vhost_includes --all-users

    Now, if I view the phpinfo for the same site (with the php.ini file in the public_html folder that has "disable_functions =" in it, I see:

    Loaded Configuration File: /usr/local/lib/php.ini

    The portion of your blog that talks about providing a specific php.ini for specific users does work for me though, as I have mentioned in another post on this forum in the past week or so.

    I have not been able to get Apache to force the use of a global php.ini using the information in your post (if I put it in /usr/local/apache/conf/includes/pre_main_global.conf). I just put the suPHP_ConfigPath directive in /usr/local/apache/conf/userdata/somefilename.conf (where somefilename.conf is a name of your choosing).

    Also, readers should be aware that when a new account is added [using the method I am using], it does not automatically inherit that configuration. After a new account is added I have to run /scripts/ensure_vhost_includes --all-users or /scripts/ensure_vhost_includes --user=new_account_username (where new_account_username = the username of the newly created account of course)

    Mike
     
  5. santrix

    santrix Well-Known Member

    Joined:
    Nov 30, 2008
    Messages:
    223
    Likes Received:
    2
    Trophy Points:
    18
    For everyone reading this, and against Mike's better judgement, to hell with it, I'm posting what mtindor and myself found out last night...

    The ONLY way to make this work is to place a conf file in

    /usr/local/apache/conf/userdata/suphp.conf

    containing:

    Code:
    <IfModule mod_suphp.c>
    suPHP_ConfigPath /usr/local/lib/
    </IfModule>
    
    This forces the use of the core php.ini for all accounts ONLY AFTER running

    /scripts/ensure_vhost_includes --all-users

    OK, so now we have the server locked down for everyone.

    Interestingly, and despite other posts stating that placing the above code in the

    /usr/local/apache/conf/includes/pre_main_global.conf

    would have the same effect, we found to be false, and this had absolutely no effect on stopping the use of local php.ini files in user accounts.

    Allowing a Custom PHP for individual users

    Then the only way to allow a custom php.ini for a single user was indeed to add a another conf file for example:

    /usr/local/apache/conf/userdata/std/2/username/mainaccountdomain.com/suphp.conf containing:

    Code:
    <IfModule mod_suphp.c>
    suPHP_ConfigPath /pathtocustomphp.ini/
    </IfModule>
    
    Then, and only after running:
    /scripts/ensure_vhost_includes --all-users
    or
    /scripts/ensure_vhost_includes --user=username

    would the settings take effect.

    The most frustrating part of all this is that when adding a NEW account to cpanel, the new account is not automatically locked down to the core.php without running /scripts/ensure_vhost_includes

    In the end (and many thanks to mtindor last night for researching this with me), it turns out that only by ALSO editing

    /usr/local/cpanel/etc/httptemplates/apache2_2/default (around line 24 as follows)

    (this was found here: InsideVHost < EasyApache3 < TWiki )

    Code:
        <IfModule mod_suphp.c>
            suPHP_UserGroup %user% %user%
            suPHP_ConfigPath /usr/local/lib/
        </IfModule>
    
    could we ensure that new accounts picked up the new settings upon creation.

    This leaves the only remaining problem of how to monitor /usr/local/cpanel/etc/httptemplates/apache2_2/default for changes because the next Cpanel update might overwrite this.

    It would be VERY nice indeed if Cpanel could incorporate the ability to amend these files on a "sticky" basis as allowing greater control over the usage of php.ini is often a core requirement for resellers of hosting, not just for security, but also to provide greater flexibility to customers.

    Thanks again Mike(mtindor) for sharing the sore eyes last night!
     
  6. santrix

    santrix Well-Known Member

    Joined:
    Nov 30, 2008
    Messages:
    223
    Likes Received:
    2
    Trophy Points:
    18
    Just to further cover the security threat posed by /scripts/upcp overwriting our modified default file, I have created a script as follows and put it somewhere safe on my server:

    Code:
    #!/bin/bash
    cd /root/scripts	
    COMPARE="`diff --brief /usr/local/cpanel/etc/httptemplates/apache2_2/default /usr/local/cpanel/etc/httptemplates/apache2_2/default.check`"
    if [ ${#COMPARE} -gt 0 ]; then
       echo "There was a change found in /usr/local/cpanel/etc/httptemplates/apache2_2/default" | /bin/mail -s "Changes in Cpanel Templates Detected `date`" admin@mydomain.com
    fi
    
    I then copied

    /usr/local/cpanel/etc/httptemplates/apache2_2/default

    to

    /usr/local/cpanel/etc/httptemplates/apache2_2/default.check

    and then set the above script to run under cron an hour after /scripts/upcp runs each night. If Cpanel change any templates overnight then I wake up to an email alert :)

    Not totally automated, but at least I know when the modified default file has been trashed.
     
  7. anton_latvia

    anton_latvia Well-Known Member
    PartnerNOC

    Joined:
    May 11, 2004
    Messages:
    348
    Likes Received:
    3
    Trophy Points:
    18
    Location:
    Latvia
    cPanel Access Level:
    Root Administrator
    Sorry for bringing this thread back to top, but this issue is still there.. I think easiest way (although may be not the best) to protect /usr/local/cpanel/etc/httptemplates/apache2_2/default is to set it to read-only mode

    Code:
    chattr +i /usr/local/cpanel/etc/httptemplates/apache2_2/default
    Anton
     
  8. anton_latvia

    anton_latvia Well-Known Member
    PartnerNOC

    Joined:
    May 11, 2004
    Messages:
    348
    Likes Received:
    3
    Trophy Points:
    18
    Location:
    Latvia
    cPanel Access Level:
    Root Administrator
    By the way - this does not seem affect PHP running in fastCGI mode. I've got server with fastCGI and local php.ini files are not being read. ;)
     
  9. cPanelTristan

    cPanelTristan Quality Assurance Analyst
    Staff Member

    Joined:
    Oct 2, 2010
    Messages:
    7,623
    Likes Received:
    21
    Trophy Points:
    38
    Location:
    somewhere over the rainbow
    cPanel Access Level:
    Root Administrator
    There's more of an issue with this method for suPHP beyond the fact new accounts aren't going to be restricted. mod_userdir also bypasses it if you have that enabled and, despite beliefs to the contrary, mod_userdir does work under suPHP

    I actually posted a guide recently about this topic:

    http://forums.cpanel.net/showthread.php?t=167186

    The PHP 5.3 method in my guide works to allow individual php.ini settings under FCGI as well actually, since it isn't handler specific.
     
  10. anton_latvia

    anton_latvia Well-Known Member
    PartnerNOC

    Joined:
    May 11, 2004
    Messages:
    348
    Likes Received:
    3
    Trophy Points:
    18
    Location:
    Latvia
    cPanel Access Level:
    Root Administrator
    Well, with FCGI under 5.2 it's a bit more manual work, but it is still possible to change per-user php settings. I had to create custom php wrapper and specify different php.ini. but as FCGI does work much faster than suPHP, it's not a big deal to do it, when you know how. ;)
     
  11. cPanelTristan

    cPanelTristan Quality Assurance Analyst
    Staff Member

    Joined:
    Oct 2, 2010
    Messages:
    7,623
    Likes Received:
    21
    Trophy Points:
    38
    Location:
    somewhere over the rainbow
    cPanel Access Level:
    Root Administrator
    For the prior discussion about editing /usr/local/cpanel/etc/httptemplates/apache2_2/default so that new accounts get restricted, I believe to keep it from getting overwritten, you could do the following so that it's in the exclude file from cPanel sync (updates):

    Code:
    echo "/usr/local/cpanel/etc/httptemplates/apache2_2/default" >> /etc/cpanelsync.exclude
    You do not want to chattr +i files. I will have to test this out. If this does work, then I'll have to revise my guide to add this part. I frankly had no idea this topic even existed when I was creating the guide and testing everything.

    Since you didn't mention how, I should link people how to do it. This is a thread post I made for how to have individual php.ini files for FCGI and CGI (and under PHP 5.2 you'd have to do it this way, while for PHP 5.3+, you can use the path include method in the guide I linked in my prior post). The thread below was posted as my non-cPanel staff account at the time.

    http://forums.cpanel.net/showthread.php?t=160398
     
Loading...

Share This Page