How to control who gets which php.ini

santrix

Well-Known Member
Nov 30, 2008
225
2
68
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?
 

mtindor

Well-Known Member
Sep 14, 2004
1,417
82
178
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
 

santrix

Well-Known Member
Nov 30, 2008
225
2
68
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!
 

santrix

Well-Known Member
Nov 30, 2008
225
2
68
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`" [email protected]
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.
 

anton_latvia

Well-Known Member
PartnerNOC
May 11, 2004
410
17
168
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
 

anton_latvia

Well-Known Member
PartnerNOC
May 11, 2004
410
17
168
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. ;)
 

cPanelTristan

Quality Assurance Analyst
Staff member
Oct 2, 2010
7,607
40
248
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.
 

anton_latvia

Well-Known Member
PartnerNOC
May 11, 2004
410
17
168
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. ;)
 

cPanelTristan

Quality Assurance Analyst
Staff member
Oct 2, 2010
7,607
40
248
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.

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. ;)
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