OK to have all .php files with 755 permissions?

As they come "out of the box", all .php files (under /includes/modules, for example) have permissions of 755.

I know about the requirement of changing the two configure.php files ASAP to 444 or 644 -- done already :smile:.

But what about all the others? Is this OK (from security standpoint) to leave them at 755?

If not, they why do they default to 755?

Other than the configure.php files, I leave all file and folder permissions as they are during installation, and haven't had a problem.

Thanks for your quick answer. I am in the process of applying some of the post v1.3.8a bugfixes and when I upload the corrected files, I notice that they have 644. That's how I noticed that all other files have 755 while the ones that I upload manually have 644. I was just wondering whether this has any significance at all.

For all kinds of reasons I would say it is a problem.

Directories with 755 is a good thing.
Files with 644 is a good thing.

Files with 755 permissions should be in a protected directory, such as the 'cgi-bin' for example.

Best to use your FTP program to upload the files which will change permissions, to the correct ones used by the Server your Hosting account is on.

Just a guess, did you use Fantastico to install Zen Cart?

Thank you Rob. I think that your guess was right on the money: I didn't install Zen Cart myself but it was rather installed by my web host's tech support. It's likely that they used Fantastico because this is one of the tools they offer.

What you say about "Files with 755 permission" makes sense. My question really was whether /includes/modules is considered a protected directory?

/includes/modules is not a protected dir. by default.

You can secure manually with an .htaccess file but not sure if will cause other problems.

<Files *.php>
Order Deny,Allow
Deny from all
Allow from localhost
</Files>

My point is/was that no PHP files need to have 755 permissions and on some Servers, running suPHP for example, it will cause problems and/or the files will just not work, period.

Script installers of many kinds; Fantastico, Joomla, Mambo for example, use the Shotgun method and apply a "one size fits all" method of installing. They create files with 755 permissions including images for some unknown reason, and sometimes create directories & files with Ownership of 'nobody'. This is a big reason why, so many sites get hacked.

Once again, thank you so much Rob for this clarification. Before I go ahead and perform a sweeping:

chmod -R 644 * ~/public_html/store/*

Is there any file in the Zen Cart system that should not be 644?

Files are generally 644 and folders are 755. That's for normal operation.

Certain files to be marked read-only are often set to 444 or in some cases 400.

If certain files need to be set read-write, the common setting is 777, but in the case of certain server configuations such as suphp it's often 755 for those specific files.

FAQ on standard settings for ZC sites: https://www.zen-cart.com/tutorials/index.php?article=9

zcnb:

Once again, thank you so much Rob for this clarification. Before I go ahead and perform a sweeping:

chmod -R 644 * ~/public_html/store/*

> Is there ***any*** file in the Zen Cart system that should **not** be 644?
If you run the command as you've shown you will have a big mess.

This would be better:
cd /public_html/store/ 
chmod -R 644 ./*.php

DrByte, I would have to disagree with your statement on some/any PHP files needing 755 permissions, but then I don't work with as many different OSs as you do. :smile:

With Linux and running any version of 'suexe' for PHP, such as suPHP, permissions of 644 is good enough for allowing the account Owner to write. This also includes scripts used/owned by the account Owner.

Website Rob:

DrByte, I would have to disagree with your statement on some/any PHP files needing 755 permissions, but then I don't work with as many different OSs as you do. :smile:

With Linux and running any version of 'suexe' for PHP, such as suPHP, permissions of 644 is good enough for allowing the account Owner to write. This also includes scripts used/owned by the account Owner.

With proper implementations of suEXE/suPHP, I'd agree with you.

What would be even better is a standard server configuration which everyone could expect to be easy to use, configure, and still be secure. Alas, we can't have everything now can we?

Thank you all for your helpful replies. Here is what I discovered so far.:

DrByte:

FAQ on standard settings for ZC sites: https://www.zen-cart.com/tutorials/index.php?article=9
I find this FAQ to be very helpful as security tightening checklist. However, while it calls for the following directories to have world-readable permissions (777):
./cache
./pub
./images
./includes/languages/english/html_includes
./admin/backups
./admin/images/graphs
I discovered that in my web host's (shared) account they are all set to 755 - and Zen Cart works perfectly. My web host is using suPHP (note that this is neither SUEXEC nor PHPSUEXEC but rather a 3rd variant).

Does that mean the FAQ needs to be corrected?

Website Rob:

If you run the command as you've shown you will have a big mess.
You are right, of course. It was simply a typo. What I intend to run is the following (in this exact sequence):

cd ~/public_html/<catalog>
find . -type d -exec chmod -R 755 {} \;
find . -type f -exec chmod 644 {} \;
chmod 444 ./includes/configure.php
chmod 444 ./admin/includes/configure.php

Do you notice any problem with the above?

I find this FAQ to be very helpful as security tightening checklist. However, while it calls for the following directories to have world-readable permissions (777):

./cache
./pub
./images
./includes/languages/english/html_includes
./admin/backups
./admin/images/graphs

I discovered that in my web host's (shared) account they are all set to 755 - and Zen Cart works perfectly. My web host is using suPHP (note that this is neither SUEXEC nor PHPSUEXEC but rather a 3rd variant).

Does that mean the FAQ needs to be corrected?
I would say 'updated' as opposed to 'corrected'. The statement/FAQ was probably written at time when using any varient of 'suexe' for PHP was not as popular as it is now. It wasn't too long ago when running PHP as an Apache module was the norm. This also goes back to what I stated in Post #6 of this thread; regarding wide open permission and making hacking so easy. This is part of the reasoning behind running PHP as CGI. It is much more secure and a lot less hacking going on. :wink:

The problem though, with updating the FAQ you mentioned, is trying to explain to non-technical people how to figure out if PHP is run as CGI. I can only presume it will happen at some point.

What I intend to run is the following (in this exact sequence):

cd ~/public_html/<catalog>
find . -type d -exec chmod -R 755 {} ;
find . -type f -exec chmod 644 {} ;
chmod 444 ./includes/configure.php
chmod 444 ./admin/includes/configure.php

Do you notice any problem with the above?
As 'find' is recursive by nature, you do not need the -R switch.

Also, due to the sweeping nature of the 'find' command, many find using the full path helps to prevent errors.

Note; run these commands one at a time and wait till finished.

find /home/userID/public_html/zencartDir/ -type d -exec chmod 0755
find /home/userID/public_html/zencartDir/ -type f -exec chmod 0644
chmod 0444 /home/userID/public_html/zencartDir/includes/configure.php
chmod 0444 /home/userID/public_html/zencartDir/admin/includes/configure.php

It does make it easy as well when using the 'history' command and also saves having to jump all over the place from using using the 'cd' command -- at least from a Server Admin POV. :smile:

Some days I hate the differences between so many possible server configurations!

Although, I do admit I've been much happier on suPHP since there's fewer permissions settings to change. And I'm told its less vulnerable to hacking. So, it's all good.

I went in and changed all my permissions according to FAQ and now the site is down and attempting to change permissions using webshell3 or filezilla is to no avail.

I cant get my site back. Help.:cry:

What error messages are you seeing?

pixelpadre:

I went in and changed all my permissions according to FAQ and now the site is down and attempting to change permissions using webshell3 or filezilla is to no avail.

I cant get my site back. Help.:cry:
Two questions;

• what is the URL to the FAQ you went by
• what prompted you to suddenly change all permissions

Answers to the above will help in providing information we can use to help you.

A. FAQ is at the top of this page.

A. Wanted to make my site as secure as possible.

pixelpadre:

... now the site is down
Um, what exactly do you mean by "down"?

Are you getting blank screens?
Error messages?

Surely there's more to the symptoms than just a vague "my site is down"?
It's really hard to help when you give nothing to go on ... :blink:

Well, my symptom was a blank white page. Since then I went with the magic of Ultraedit and batch deleted much of the inserted text at the bottom of every file. I still have files with a different string to remove but ultraedit cannot not do it because the text to be removed includes ascii strings which fakes the software into saying we find no occurances. All of my images have been infected as well....chmod 777 images directory?

My mistake seems to be assigning 777 to the directories as advised in the FAQ for zen folder permissions.

This nasty infection went clear through my root directory, infecting every website I own.

It might be even more thorough to use a clean set of backup files, rather than mass-editing files to only remove obvious damage. What happens if you miss something they didn't do using the same pattern?
If someone is doing malicious activity when you've got certain folders set to 777 permissions, then the server itself is at risk, not just your site. You can certainly override the 777 with something lower such as 755, but you'll lose the ability to upload images or edit define pages via your admin. And customers won't be able to upload files with their orders (if you're using that feature).

FAQ on Recovering from Hack Attempts: http://www.zen-cart.com/wiki/index.php/Recovering_From_Hacks