Updated Apache/PHP, now "Access Forbidden" on all sites

[Xinil]

I recently upgraded my Apache to 2.2.9 and my PHP to 5.2.6 (from 5.2.4). After the update, all my websites come up as "Forbidden." If I "chmod 777 public_html" on all the domain directories, the forbidden goes away. I shouldn't have to have my public_html 777 though.

I turned off "Apache suEXEC", but I've also tried it On, no difference. When viewing phpInfo on a site, the User/Group shows up as: nobody(99)/2.

Any help would be appreciated. Thanks.

[Xinil]

Bump? ~ Is this not a common problem people have experienced?

[mtindor]

SuEXEC is for CGIs
SuPHP is for PHP

If you have your Apache compiled with SuPHP and are running the SuPHP handler, then you need to have all of your sites adhere to certain file permissions / ownership.

All files should be owned by the user
Directories should be no more than chmod 755
PHP files should be no more than chmod 644
CGI scripts (if SuEXEC enabled) should be no more than chmod 755
You'

You can get away with even stricter permissions in many cases, but you'll get Internal Errors when trying to pull up PHP pages or run CGIs if you have SuEXEC or SuPHP active and do not have appropriate permissions.

/home/account (chmod 711) - not recursive
/home/account/public_html (chmod 750) - not recursive
php files - chmod 644 or less
CGIs / PERL scripts - chmod 755
directories / files - not chmod 777

That's the way our setups are. Like I said, you can be even more restrictive in many cases.

Mike

[mtindor]

If your goal is _not_ to run SuPHP, make sure it is not compiled in Apache - or go into WHM / Configure PHP and SuEXEC (under Server Configuration) and set the PHP handler to DSO or CGI - whichever is your choice. Then you'll have to do all the stuff with making sure directories have certain permissions if the webserver needs to write to them, etc.

If your goal _is_ to run SuPHP, then read my previous post.

I'm sure others will chime in with additional info. This is often talked about on the forums, and a search for something like SuPHP permissions might give you some results to chew on.

Mike

[Xinil]

Thanks for the help, mtindor. Do I want to run suPHP or not? Before I updated Apache, when I created a new account on my server, the site came up fine. Now, when I create a new account, the site come sup as "403 Forbidden."

I guess my question is, what do I have to set my settings to, so that when I create a new account, it doesn't come up as "403 Forbidden." I do not want to have to keep "chmod 777 public_html" on all my new accounts.

Thanks again.

[mtindor]

That's a good question.

Do you have SuPHP handler enabled currently in WHM / Configure PHP and SuEXEC? Does it list suphp as the handler?

If so, then I'm thinking that any new account you create after that should already be ready to go and get created with appropriate permissions.

If it does not, you should open a ticket with Cpanel about it. You definitely should not have to manually set the permissions on _new_ accounts after changing to using SuPHP.

I really can't advise you on whether you should use SuPHP or not.

PROS: Better security. When you enable SuPHP, each account's PHP is executed as that user (rather than 'nobody'). This helps to isolate / limit the scope of mischief that can be done if you have a PHP application that gets hacked.

If you do not run SuPHP and a website gets hacked, it is much easier for the perpetrator to wreak havoc on all other sites. If you _do_ run SuPHP, then it is more difficult for a hacked site to be used to destroy all of the other sites on the server since each site's files will be owned by a separate user.

CONS: If you are running a really low end machine, you may see a performance decrease. There is a performance hit.

Another CON is that you can't put php values in .htaccess files anymore if you run SuPHP. Instead you'd have to have your customers enter their specific PHP values (if they have any) in a php.ini file that then needs to be copied to every directory that their PHP application requires. This isn't always a problem.... but it does come up from time to time.

For instance, in a non-suPHP environment, if somebody wanted to turn register_globals on for their site, they could do so via a line in the .htaccess file in their public_html or specific application folder and that setting would be inherited by all files and subdirectories below where you put it. On the other hand, if you run in an SuPHP environment you'd have to turn register_globals on in an individual php.ini file that gets placed in the application's directory (and possibly would then have to be copied to other subdirectories underneath the application directory).

From a security standpoint, I prefer it. Other's may feel differently. Ask around, read these forums, do some searches to find out.

If you aren't concerned about security, you should be. If you are concerned about security, then you'll also want to consider running mod_security with a good set of rules (search for mod_security on these forums and read about it). You'll also want to harden your master php.ini file as well. I can't get into it all. All of these things have been discussed countless times here. So you'll ultimately have to do the readnig and make the decision.

So, consider enabling SuPHP and getting all your current sites running with it ( search these forums for suphp file permissions ). And consider using mod_security with a good set of rules (search these forums for mod_security rules ). And consider editing your master php.ini file ( search on these forums for hardening php security ). Then mix up your searches with a combination of those, read the threads, and make your decision.

I'm no expert. I learn every day from these forums. There is a wealth of information if you care to spend some time.

Mike

[Xinil]

In case anyone is having the same problem, to resolve this turn off "FileProtect" in your Apache settings.

Answer came from cPanel support.