Enabling suPHP as the PHP 5 handler breaks WHMCS?

[DH - Tristan Perry]

Hey all,

I've recently been tinkering with the PHP security settings and I've come across a weird issue. I'm running PHP 5.2.9 and WHMCS 4.0 stable.

 

I've noticed that when I compile suPHP/suExec and suHosing support into PHP (the norm for selling shared hosting), when I enable suPHP as the PHP 5 handler (instead of dso), it breaks WHMCS in the following ways (may be more issues, these are the ones I've found):

 

1) When I'm in the admin panel and click "Login as Client" under a client (I haven't yet started selling hosting - this is just a test client don't worry!), it goes my WHMCS client area but the user isn't logged in and it gives an error message saying the username or password is wrong

 

2) When ordering, when I select a domain (or tell it to update the DNS on an existing domain), I select the "Next" button and it goes back to the order homepage. Viewing the cart shows that the product and domain aren't in the card anymore/at all.

 

This is very weird. I literally change to dso as the PHP 5 handler and it works fine. I change to suPHP and the above issues occur straight away.

 

Any suggestions? Do I need to modify something in suphp.conf?

 

Many thanks,

Tristan Perry

[sparky]

Check your session_path and ensure that that directory has 1777 perms

[DH - Tristan Perry]

Looking in php.ini, the session_path is still the system default (/tmp I think), and the directories all have correct permissions. Or should I be looking elsewhere for the session_path?

[Lawrence]

I wouldn't run suPHP and Suhosin at the same time. I tried it once and it broke alot of PHP scripts. Your best best would be simply use suPHP as it will still allow 99% of PHP scripts to run as expected, and provide good security at the same time.

[DH - Tristan Perry]

I wouldn't run suPHP and Suhosin at the same time. I tried it once and it broke alot of PHP scripts. Your best best would be simply use suPHP as it will still allow 99% of PHP scripts to run as expected, and provide good security at the same time.

Thanks for the advice

 

I've disabled suHosin/recompiled without it now, although WHMCS is still broken.

[keliix06]

We run suPHP and Suhosin on all of our shared servers (and our server with WHMCS) and have no problems. Occasionally we need to tweak a suhosin rule, but that's all.

[hightekhosting]

Hello,

 

We run WHMCS V4 with suHosin and suPHP without any drama's whatsoever.

 

We have implemented extra security features of WHMCS as well as a few other things.

 

I would think that with regards to your issue, something is not right, so I would like you to run the following commands, one by one, within SSH on your server (if running cPanel which I presume you are):

 

/scripts/postsuexecinstall
/scripts/chownpublichtmls
cd /home
find -perm 777 -exec chmod 755 {} \; -print
find -perm 666 -exec chmod 644 {} \; -print
/scripts/fixsuexeccgiscripts

 

This will check all permissions are suitable for suPHP and if not, change them accordingly.

 

Basically, any file that is chmodded 777 will not work under suPHP and throw errors, so it needs to be changed to 755 and the same applies for 666

 

Let me know how you go

 

Regards,

 

Dale E

[MACscr]

I wouldn't run suPHP and Suhosin at the same time. I tried it once and it broke alot of PHP scripts. Your best best would be simply use suPHP as it will still allow 99% of PHP scripts to run as expected, and provide good security at the same time.

 

We run both on all of our servers and it works just fine. Including with whmcs.

[DH - Tristan Perry]

Thanks for the replies all

 

Dale - you are a genius It was because I had originally chModded some files 777 with the original installation. I thought I'd reset them all, but apparently not (I've moved some out of the public_html folder as recommended, and then forgot about them!)

 

Out of interest, is there a way with a suPHP set-up to, instead of showing an ugly 500 error message when someone chMods to 777/666, simply 'reject' that chMod and auto-set the files to 755 and 655? If not, I guess I could add that command to an hourly cron or something to minimise the damage so to speak?