SuPHP + Apache 2 = No PHP Security

[LBJ]

G'day All,

We've just recently moved a few of our servers to Aache 2, running PHP4 & PHP5 via SuPHP, but we've now stopped the upgrades and are doing a bit of head scratching.

Like most hosts, we have extensive optimizations and security options configured in each of the php.ini files for both the PHP4 & PHP5 installations. We also run suhosin with appropriate configurations in each of the php.ini files for both PHP4 & PHP5.

As we had expected, SuPHP allows our users to override server wide php.ini values with a local php.ini in the folder where their php is executed. That's how our previous configurations operated and it always worked well for our clients. We have a cron that reports any user php.ini modifications to us so we can deal with problems of security immediately. It's always allowed a degree of flexibility to our users while still allowing us to keep things relatively tight.

However, with the new SuPHP operation, what we hadn't expected was that even a totally empty php.ini dropped into the user's folder will force PHP4 & PHP5 execution back to a vanilla configuration. The server wide php.ini is not inherited and modified by the user's php.ini, but instead it's totally replaced.

If a php.ini is created in the user's folder, all security defines (disable_functions, register_globals, memory_limit etc.) and suhosin configurations are simply dismissed.

Zend Optimizer, ionCube and all other php.ini dependent inclusions are also tossed.

Reading carefully over CPanel's EA3 documentation again, I see the above behavior is exactly as expected, but we're finding it close to unworkable. If an end user creates a php.ini to tweak a single setting, they've effectively negated all our defaults.

I'd be really interested to hear how others are working with SuPHP's way of handling things.

Thanks for any ideas and feedback.

Best Regards,

LBJ

[bornonline]

Geez.. you are correct. Placing the empty PHP.ini kills the custom PHP config. Suhosin is disabled and all the PHP functions that should be disabled are NOT. This scares me since I had to add PHP.ini to customers sites that use OScommerce after the upgrade to SuPHP. I did not want to enable register_globals server wide so I thought this would be ok. This is anything but ok. What to do

[jdlightsey]

Reading carefully over CPanel's EA3 documentation again, I see the above behavior is exactly as expected, but we're finding it close to unworkable. If an end user creates a php.ini to tweak a single setting, they've effectively negated all our defaults.

This isn't a mod_suphp or cPanel specific problem. It's the normal behavior of PHP when running as a CGI binary. See http://us3.php.net/configuration for details.

cPanel's version of mod_suphp provides a little help with this problem by allowing you to lock the php.ini file down in suphp.conf. I believe the particular patch that accomplishes that will be merged into the next upstream version of mod_suphp.

That doesn't really do what you're hoping to accomplish though (allowing for a local php.ini to modify some settings without replacing the full contents of the standard php.ini.) For that you would need to set the --config-file-scan-dir flag.

In the past we set the --config-file-scan-dir flag to run over the normal php.ini file with the SafePHPCGI option in EasyApache 3, but it caused problems when the Zend Optimizer was installed and php.ini was a symlink. (PHP's startup routines would read the php.ini file twice and have errors.) As a result we changed the SafePHPCGI option to set --config-file-scan-dir=/usr/local(/php4)/lib/php.ini.d. Since then we've changed the way Zend Optimizer gets installed so that it should no longer turn the standard php.ini into a symlink. It might be safe to undo the change to --config-file-scan-dir and get the old behavior out of SafePHPCGI. If that's the case, you'd just need to select SafePHPCGI in the EA3 interface.

I'm running a few tests now to see if we can safely switch the behavior of the SafePHPCGI option back.

[jdlightsey]

I should have tested before I wrote initially. Setting --with-config-file-scan-dir so that PHP sees the normal php.ini file causes PHP to attempt loading extensions twice regardless of whether or not php.ini is a symlink. So the EA3 SafePHPCGI will need to stay as-is.

So, if you want PHP to magically merge php.ini files together, you have a couple options.

1) Recompile with the SafePHPCGI option enabled and move the configuration directives you want to guarantee are loaded from /usr/local(/php4)/lib/php.ini to /usr/local(/php4)/lib/php.ini.d/php.ini. If you go this route you'll need to manually restore your changes when you recompile PHP or update an extension using /scripts/phpextensionmgr.

2) You can install the htscanner PECL module and use it to make PHP running as a CGI aware of the settings in .htaccess files. I don't have any experience with this PECL module but you can read more about it here:

http://pecl.php.net/package/htscanner
http://cvs.php.net/viewvc.cgi/pecl/h....3&view=markup

If those seem like too much work, just copy the system php.ini file when you want to change a particular setting.

[bornonline]

So you are saying just place the system PHP.ini file in the users directory? Just want to make sure I understand.

[LBJ]

This isn't a mod_suphp or cPanel specific problem. It's the normal behavior of PHP when running as a CGI binary. See http://us3.php.net/configuration for details.

No, I completely understand that. As I wrote...

Reading carefully over CPanel's EA3 documentation again, I see the above behavior is exactly as expected...

If those seem like too much work, just copy the system php.ini file when you want to change a particular setting.

Yes, that's obviously the solution, but the problem is in expecting end users to follow such a procedure. It just isn't going to happen.

Typically the end user will simply create a php.ini with just the over-ride to the one directive expecting that to be the only change implemented. Of course with SuPHP, that does a lot more and completely negates our own configuration including optimizations, security, suhosin, Zend Optimizer and ionCube.

What we've done now is modified our existing cron which detects modified user php.ini files, sends us a report of the file contents, and then merges our default php.ini directives into the end user's local php.ini at each level it exists at or below the public_html.

It's kludgey, but it does the job.

[isputra]

What we've done now is modified our existing cron which detects modified user php.ini files, sends us a report of the file contents, and then merges our default php.ini directives into the end user's local php.ini at each level it exists at or below the public_html.

It's kludgey, but it does the job.

Would you give me step by step to do like yours ? Thanks

[qwerty]

I'd love a copy of this script too ;-)

[vidarn]

Sorry for bumping an "old" thread, but I would just like to say that the htscanner module
works okay - but that you will need to enclose php-specific instructions in the .htaccess files
with <IfModule mod_php.c>-tags for them to be interpreted correctly. There seems to be a
patch to remove the need for the tags for Apache 2.0.59, if anyone knows of a way to
circumvent this on Apache 1.3.41 I'm very interested.