PHPSuExec being installed on existing servers »» Tips and tricks

Dear Customers,

We'd like to announce that we have installed PHPSUEXEC on a few of our existing servers.

A few changes might be needed on your website's configuration files (.htaccess) (do not panic ).

All the php_flags in your .htaccess will have to be moved to php.ini, which you will have to create in your public_html directory.

Example:
.htaccess » php_flag register_globals on
php.ini » register_globals=on

The file php.ini will handle all the extra settings you need to set in php.
So, basically you will have to move every command on .htaccess that starts with php_flag.

Differences between phpsuexec and "regular php":
When using the common PHP installation on a webserver, php runs as the user nobody and it doesn't require the execute flag to be enabled.

The problem on this is that if mod_openbasedir is not installed (we have this at HostGator), every user will be able to read your php files because everyone is virtually sharing the same username (nobody).

As most of you already know, PHP Files are not meant to be read, but parsed, and that is where the problem resides. PHP Files have to be parsed, otherwise everyone who is able to read your php file will see settings that you would probably want to keep private, such as your MySQL username and password.

PHPSUEXEC fixes all this because it requires php to be run as the file owner's username. (for example: andre)

This is not everything it fixes though. PHPSUEXEC is also here to fix file ownership problems. This has been a common issue on a few Content Management Systems such as Joomla and also on the popular blog software: WordPress.

It also adds security to your files as you can use permissions such as 600 or 700 in your files and your visitors will still be able to view them (parsed) in their browsers.

PHPSUEXEC will also refuse to serve any pages that are at security risk, for example with 777 as permissions. (will generate an Internal Server Error)

Troubleshooting Internal Server Errors (Error 500):
Everytime an internal server error occurs, it will be added to your Error Log in cPanel. (cPanel »» Error Log). This will usually give you a clue on where the error resides. In most cases it will be either a permission error on a bad command in your .htaccess file (remember that all php values have to go to your php.ini file).

Directories that need to be written onto will no longer require 777 as permissions and phpsuexec will refuse to write or read on directories exposed with such permissions. You will have to chmod them to 755 always.

To simplify it, just remember that you should never have a file or folder with world-writeable permissions, because you no longer have to.

MIMETypes:
If you added a Mimetype to the system in order to run html files as php scripts (AddType as .htaccess command), you will have to remove it and add an ApacheHandler instead. This is easy to do though. Just log into your control panel, then click on Apache Handlers and add the following:

Extension: html (or htm)
Handler: application/x-httpd-php

QuickStart for impatient users :
Technically, PHPSUEXEC will make sure your scripts and directories abide by the following security rules:

• User executing the wrapper must be a valid user on the server.
• The command that the request wishes to execute must not contain a /.
• The command being executed must reside under the user's web document root (public_html).
• The current working directory must be a directory.
• The current working directory must not be writeable by group or other.
• The command being executed cannot be a symbolic link.
• The command being executed cannot be writeable by group or other.
• The command being executed cannot be a setuid or setgid program.
• The target UID and GID must be a valid user and group on the system.
• The target UID and GID to execute as, must match the UID and GID of the directory.
• The target execution UID and GID must not be the privileged ID 0.
• Group access list is set to NOGROUP and the command is executed.

Protecting your php.ini file:
To protect your php.ini you should set its permissions to 600. Additionally you can add the following line to your .htaccess file:

<Files *.ini>
  Order deny,allow
  Deny from All
</Files>

WordPress Bloggers:
If you encounter any problems with your .htaccess file (mod_rewrite instructions), you can fix this by downloading the following:
http://boren.nu/archives/2005/03/07/...ewrite-plugin/

We have updated WordPress in Fantastico so it is configured for phpsuexec from the start. So if you are desperate you can always reinstall WordPress from Fantastico. (Just remember to download a database backup first!). After it's installed, just change your MySQL configuration settings in WordPress.

Drupal and other Content Management Systems:
You might experience a few errors, such as "Call to undefined function: user_access()". Add the following code to php.ini to fix it:

session.save_handler = files
session.cache_limiter = nocache

That's it. I know it may look complicated to some of you, but it should be technically easy.

I am subscribed to this thread, so if you need any help on this you can reply to it (it is preferrable to ask for help here so other users can also find the information they are looking for, if they have the same problem).

Thanks!

[esl]

So I have to do this to my main reseller account AND my clients'?

[TeeJa]

I hope you dont mean dedicated to? I do not have time to make those kind of changes.....

[vtrain]

can we know which servers are alredy changed and the schedule for our server?

Vt

Hello there,

Originally Posted by esl

So I have to do this to my main reseller account AND my clients'?

Only to those with problems.
The php.ini file is not necessary unless you have been using extra php configurations in .htaccess as I described above to prevent errors.

Sites that do not use any special .htaccess or php configurations should work with no problems at all.

You can just pass this information to your clients so they know what to do, unless you provide coding support as well. (in that case you will have to do it )

Originally Posted by TeeJa

I hope you dont mean dedicated to? I do not have time to make those kind of changes.....

No, we would only change that in your server if you had requested it.
PHPSuExec is recommended, though you are not forced to change at all, that's just my advice.

Originally Posted by vtrain

can we know which servers are alredy changed and the schedule for our server?

Vt

As of now, the following servers are running phpsuexec:

• Kia
• Gator92
• Gator94
• Vanquish

We will add it to existing servers one at a time, so you will be informed once this takes place. I recommend you to start working on the php.ini thing as soon as possible though, so whenever it is installed on your server you already have everything modified and just need to upload.

[esl]

Thank you for the quick reply Andre!

Originally Posted by esl

Thank you for the quick reply Andre!

You're welcome

I do not think your server already has it installed though.
A good way of checking this out is to place a phpinfo file on your website's public_html directory.

Simply create a new file with the name phpinfo.php and add the following code to it:

<? phpinfo(); ?>

Then save the file and access it with your browser.
You should look for Server API on it (4th row). If it says CGI it means you are using phpsuexec. If it says APACHE, then it means you are not using it yet.

[jeff_s]

How will we know when our server is changed over? Is there a web page with scheduled/completed dates for each server? This would be very helpful for this upgrade as well as others. It doesn't have to be pretty or fancy ... a text file is fine. Please, HG, communicate with your clients, please?

Jeff_s
HG Reseller

Originally Posted by jeff_s

How will we know when our server is changed over? Is there a web page with scheduled/completed dates for each server? This would be very helpful for this upgrade as well as others. It doesn't have to be pretty or fancy ... a text file is fine. Please, HG, communicate with your clients, please?

Jeff_s
HG Reseller

I don't think we have any list for that yet, however you will be informed either via email or here on the General Announcements forum, Jeff.

[jas01724]

I use mod_rewrite throughout my entire main site. Reading through the documentation of problems with Wordpress' rewrite engine, I'm concerned that my own current rewrite rules may not work as intended with PHPSUEXEC. Can you please clarify any potential problems, and the workarounds?

[vtrain]

one of my clients is using phpBB with template_file_cache.php. This means there is a directory with 777 permission that I have to check everyday if something strange is there... (the directory is .htaccess protected but still)

8.iii. Optional extras

Included with this package are two extra (optional) files, you will find them in the contrib/ directory. These extras, template_file_cache.php and template_db_cache.php address concerns over server load and page generation times on slower or heavily loaded systems. These updated template modules compile each template and uses this rather than compiling each file everytime it is viewed. Tests seem to indicate a noticeable decrease in page generation times and more importantly a significant decrease in overall server load in virtual hosting environments.
http://www.phpbb.com/support/documents.php?mode=install

I would be happy to change this diretory to 755 and have less burden over me. BUt if I change now... the phpBB would break. So having a estimation on when this change will happen on a particular server would be important.

Vt

[jas01724]

Originally Posted by vtrain

So having a estimation on when this change will happen on a particular server would be important.

Ditto. I've already uploaded a php.ini file containing everything that I require, but for now I'm still reliant on php_flag in the htaccess file. Much like a directory with CHMOD set at 777, I understand that php_flag generates an Internal Server Error once PHPSuExec is activated. I would obviously want to get rid of that error as quickly as possible.

[kmaw]

This sounds awesome, from the way I understand it, because I've had terrible troubles with Joomla sites lately.

[Serra]

The target UID and GID to execute as, must match the UID and GID of the directory.

I'm currently uploading files using both Perl and PHP. The PHP uploads go into a 777 directory. If I upgrade to PHPSuExec, will there be a problem with this?

I can chmod the directories to 755 (per instructions), but the files in the directory are a mix of owner "user" and "nobody". Will I need to chown the files to "user" or can PHP scripts running as "user" under PHPSuExec be able to write to 755 "nobody" files?

Originally Posted by jas01724

I use mod_rewrite throughout my entire main site. Reading through the documentation of problems with Wordpress' rewrite engine, I'm concerned that my own current rewrite rules may not work as intended with PHPSUEXEC. Can you please clarify any potential problems, and the workarounds?

It depends on the rules. There is always a workaround though, it just depends on what exactly you're using. You may need to modify a few commands on it to make it usable in phpsuexec, however not all of them. Actually, there are more commands compatible then incompatible. And those incompatible aren't really incompatible, you just need to change their syntax.

Originally Posted by jas01724

Ditto. I've already uploaded a php.ini file containing everything that I require, but for now I'm still reliant on php_flag in the htaccess file. Much like a directory with CHMOD set at 777, I understand that php_flag generates an Internal Server Error once PHPSuExec is activated. I would obviously want to get rid of that error as quickly as possible.

Yes, php_flag will generate an internal server error no matter what.
Directories will have to be 755 always. 777 will generate an internal server error as well.

Originally Posted by kmaw

This sounds awesome, from the way I understand it, because I've had terrible troubles with Joomla sites lately.

A lot of users had problems of file ownership in Joomla. PHPSuExec will fix this, as there will be no confusion of usernames. PHPSuExec will always write those files with your username, so you will always be able to access them and change their permissions (no more permission denied errors)

Originally Posted by Serra

I'm currently uploading files using both Perl and PHP. The PHP uploads go into a 777 directory. If I upgrade to PHPSuExec, will there be a problem with this?

I can chmod the directories to 755 (per instructions), but the files in the directory are a mix of owner "user" and "nobody". Will I need to chown the files to "user" or can PHP scripts running as "user" under PHPSuExec be able to write to 755 "nobody" files?

You will most likely need to chown them to your username for them to work. You will no longer be able to write "nobody" files on PHPSuExec, they will always be written with your username as the owner, no matter what and how you try to write them.

Basically PHPSuExec has the same rules as CGI's SuExec.

Same rules, same precautions, same errors. This will be good as it will force you to make your scripts secure.

[newhall]

Will this affect my osCommerce site at all? I have several LIVE sites that use osCommerce (using PHP and MySQL) and I cannot afford to have any problems.

Do I have to make any changes?

[gtgeorge]

I know it will affect Zen cart as they will have the permission issues as I believe oscommerce has the same permissions. Trying to watch for the change as we have several carts and gallery sites to take care of when the change occurs.

Originally Posted by newhall

Will this affect my osCommerce site at all? I have several LIVE sites that use osCommerce (using PHP and MySQL) and I cannot afford to have any problems.

Do I have to make any changes?

You will also need to change a few things there depending on what osCommerce uses. The quickest fix would be to reinstall it from Fantastico (of course saving your database first) and then modify the DB Connection information in osCommerce so it connects to the existing DB (also apply any modifications made like themes, etc).

The other route is to change the permissions and php_flags manually.

[newhall]

Unfortunately, our osCommerce installation is about 50% customized with literally hundreds of modifications and improvements. We would have to make changes manually to whatever files HostGator mentioned. It's impossible to use Fantastico to reinstall.

May I request not updating our server since it would be a HUGE problem for us if something breaks? In the alternative, can HostGator check what exact changes will need to be made vis-a-vis osCommerce (if different from what already mentioned in this thread) and post a step by step of what we would need to change on our end.

Thanks!

[Serra]

Originally Posted by newhall

Unfortunately, our osCommerce installation is about 50% customized with literally hundreds of modifications and improvements. We would have to make changes manually to whatever files HostGator mentioned. It's impossible to use Fantastico to reinstall.

Ask that your account (the osC one only), be moved to a server that already has PHPSuExec on it and see how it works first. From what I can tell, one chmod and one chown should eliminate all of the problems.

[Serra]

GatorAndre,

SuExec can be enabled/disabled in WHM, is the same true for PHPSuExec?

Originally Posted by newhall

Unfortunately, our osCommerce installation is about 50% customized with literally hundreds of modifications and improvements. We would have to make changes manually to whatever files HostGator mentioned. It's impossible to use Fantastico to reinstall.

May I request not updating our server since it would be a HUGE problem for us if something breaks? In the alternative, can HostGator check what exact changes will need to be made vis-a-vis osCommerce (if different from what already mentioned in this thread) and post a step by step of what we would need to change on our end.

Thanks!

Normally you only need to move the php directives to php.ini and change your permissions. The rest would stay intact.

Originally Posted by Serra

GatorAndre,

SuExec can be enabled/disabled in WHM, is the same true for PHPSuExec?

PHPSuExec can be enabled/disabled in WHM when recompiling apache (of course it requires you to recompile it).

WHM » Software » Apache Update
(you should enable PHP suEXEC Support)

[Serra]

Originally Posted by GatorAndre

WHM » Software » Apache Update
(you should enable PHP suEXEC Support)

Well, if that isn't just the most amazing menu in WHM!

[chaloupe]

I got one crazy question here, if I enable PHPSuExec,

Could this mean that it could help the Mambo user on my server that I have to always "chmod -R" new folder they upload via the admin interface in a .zip files to work properly as soon as they upload it? and not me having to "chmod -R" every time a new modules or new components is installed and the client has to email me the new components to me so I can chmod -R?

I got this weird issue with those mambo project website on my server about uploading new components and user are not able to access it or open it after they have upload it via the Admin Interface. I should check the user group to see to who it comes after they upload also next time.

[quietFinn]

Originally Posted by chaloupe

I got one crazy question here, if I enable PHPSuExec,

Could this mean that it could help the Mambo user on my server that I have to always "chmod -R" new folder they upload via the admin interface in a .zip files to work properly as soon as they upload it? and not me having to "chmod -R" every time a new modules or new components is installed and the client has to email me the new components to me so I can chmod -R?

Yes.
When Mambo is running as the user of the website there is no need any more to chown files/directories

Originally Posted by chaloupe

I got this weird issue with those mambo project website on my server about uploading new components and user are not able to access it or open it after they have upload it via the Admin Interface. I should check the user group to see to who it comes after they upload also next time.

There is a component named MamboXplorer (and JoomlaXplorer), it's a file manager running in Mambo/Joomla and as the same user as Mambo/Joomla does, and therefore it is able to access the files/directories created by Mambo/Joomla.