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.

SuPHP + Apache 2 = No PHP Security

Discussion in 'EasyApache' started by LBJ, Jan 25, 2008.

  1. LBJ

    LBJ Well-Known Member

    Joined:
    Nov 1, 2003
    Messages:
    56
    Likes Received:
    0
    Trophy Points:
    6
    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
     
  2. bornonline

    bornonline Well-Known Member

    Joined:
    Nov 19, 2004
    Messages:
    139
    Likes Received:
    0
    Trophy Points:
    16
    Location:
    Earth
    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 :confused:
     
  3. jdlightsey

    jdlightsey Perl Developer III
    Staff Member

    Joined:
    Mar 6, 2007
    Messages:
    126
    Likes Received:
    2
    Trophy Points:
    18
    Location:
    Houston Texas
    cPanel Access Level:
    Root Administrator
    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.
     
  4. jdlightsey

    jdlightsey Perl Developer III
    Staff Member

    Joined:
    Mar 6, 2007
    Messages:
    126
    Likes Received:
    2
    Trophy Points:
    18
    Location:
    Houston Texas
    cPanel Access Level:
    Root Administrator
    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/htscanner/README?revision=1.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.
     
  5. bornonline

    bornonline Well-Known Member

    Joined:
    Nov 19, 2004
    Messages:
    139
    Likes Received:
    0
    Trophy Points:
    16
    Location:
    Earth
    So you are saying just place the system PHP.ini file in the users directory? Just want to make sure I understand.
     
  6. LBJ

    LBJ Well-Known Member

    Joined:
    Nov 1, 2003
    Messages:
    56
    Likes Received:
    0
    Trophy Points:
    6
    No, I completely understand that. As I wrote...

    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.
     
  7. isputra

    isputra Well-Known Member

    Joined:
    May 3, 2003
    Messages:
    576
    Likes Received:
    0
    Trophy Points:
    16
    Location:
    Mbelitar
    Would you give me step by step to do like yours ? Thanks
     
  8. qwerty

    qwerty Well-Known Member

    Joined:
    Jan 21, 2003
    Messages:
    213
    Likes Received:
    0
    Trophy Points:
    16
    I'd love a copy of this script too ;-)
     
  9. vidarn

    vidarn Member

    Joined:
    Jun 22, 2007
    Messages:
    8
    Likes Received:
    0
    Trophy Points:
    1
    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.
     
Loading...

Share This Page