[quote name=‘Lantan’]I will expain, why we recommend 777/666. It is exactly because there can be “different users for PHP and FTP” on a server.
For example, If you upload all the CS-Cart files by FTP to your server, you will be unable to change them via CS-Cart (that acts as a PHP user) if there are not enough permissions on them. It means, the template editor and upgrade center (without the FTP access) will not work for you. And some other problems with the ‘access denied’ error may occur as well.
As a result, the CS-Cart source files are uploaded by FTP while the skin and product image files are created by the PHP user. Having 777/666 permission on all these files is the easiest way (I agree, not best) to upgrade everything smoothly.
Thank you.[/QUOTE]
Alex, That method creates a bad problem with your clients that are hosted on servers running PHP with suphp or fcgi handlers and nearly all hosting companies are now doing this for security reasons. Having 666/777 permissions set on these environments will cause errors in most cases.
Only servers running ‘mod_php’ will have different users for FTP and PHP and most of your clients are ‘not’ hosted in that environment anymore. Depending on server security configuration, this may still not allow Apache owned files to be edited or removed by the user…
Please also stop ‘forcing’ these permissions during the archive extraction and also with this coding in config.local.php since this is incorrect for most clients.
```php
// Default permissions for newly created files and directories
define(‘DEFAULT_FILE_PERMISSIONS’, 0666);
define(‘DEFAULT_DIR_PERMISSIONS’, 0777);
```
Thank you
Hello S-Combs,
[quote name=‘S-Combs’]Alex, That method creates a bad problem with your clients that are hosted on servers running PHP with suphp or fcgi handlers
[/QUOTE]
Do you mean the problem for hosting providers? Please, clarify this problem in more detail.
[quote name=‘S-Combs’]
and nearly all hosting companies are now doing this for security reasons. Having 666/777 permissions set on these environments will cause errors in most cases.
[/QUOTE]
I am sorry, I am not a system administrator. Please, let me know what kind of problems it causes.
[quote name=‘S-Combs’]
Only servers running ‘mod_php’ will have different users for FTP and PHP and most of your clients are ‘not’ hosted in that environment anymore. Depending on server security configuration, this may still not allow Apache owned files to be edited or removed by the user…
[/QUOTE]
Do you mean by FTP? What solution can you offer in such a case (if there is no ability to run PHP with suphp or fcgi handlers)?
[quote name=‘S-Combs’]
Please also stop ‘forcing’ these permissions during the archive extraction and also with this coding in config.local.php since this is incorrect for most clients.
```php
// Default permissions for newly created files and directories
define(‘DEFAULT_FILE_PERMISSIONS’, 0666);
define(‘DEFAULT_DIR_PERMISSIONS’, 0777);
```
Thank you[/QUOTE]
Do you mean, we should NOT set any permissions on the files that are created during the CS-Cart installation or what “archive extraction” do you mean?
Thank you.
[quote name=‘Lantan’][QUOTE]—Quote (Originally by S-Combs)—
Alex, That method creates a bad problem with your clients that are hosted on servers running PHP with suphp or fcgi handlers
—End Quote—
Do you mean the problem for hosting providers? Please, clarify this problem in more detail.[/QUOTE][/QUOTE]
This is a problem for the client, hosting provider and CS-Cart forum members when a server is running suphp or fcgi. Because, when incorrect permissions are applied, the clients site will break and they will then need to ask for help ‘somewhere’.
[quote name=‘Lantan’][QUOTE]—Quote (Originally by S-Combs)—
and nearly all hosting companies are now doing this for security reasons. Having 666/777 permissions set on these environments will cause errors in most cases.
—End Quote—
I am sorry, I am not a system administrator. Please, let me know what kind of problems it causes.[/QUOTE][/QUOTE]
suPHP will not allow permisions of 666 or 777 and it will result in 500 errors if these are applied.
[QUOTE]Quoted from the suPHP.conf documentation here
[url]http://www.suphp.org/DocumentationView.html?file=CONFIG[/url]
allow_file_group_writeable:
Allow files to be group writeable. Is disabled by default.
allow_directory_group_writeable:
Allow directories scripts are residing in to be group writeable.
Is disabled by default.
allow_file_others_writeable:
Allow files to be writeable by world. Is disabled by default:
WARNING: Enabling this option is very dangerous and causes major
security issues, especially the danger of arbitrary code execution!
allow_directoy_others_writeable:
Allow directories scripts are residing in to be writeable by world.
Is disabled by default:
WARNING: Enabling this option is dangerous!
[/QUOTE]
[quote name=‘Lantan’][QUOTE]—Quote (Originally by S-Combs)—
Only servers running ‘mod_php’ will have different users for FTP and PHP and most of your clients are ‘not’ hosted in that environment anymore. Depending on server security configuration, this may still not allow Apache owned files to be edited or removed by the user…
—End Quote—
Do you mean by FTP? What solution can you offer in such a case (if there is no ability to run PHP with suphp or fcgi handlers)?[/QUOTE][/QUOTE]
Only servers running mod_php (DSO) will make files created by PHP owned by the Apache user because PHP is ran as the Apache user. suPHP forces PHP to run as the user who owns the script (same as FTP user).
My solution is simple: Please stop recommending and enforcing these 666/777 permisions because these no longer work on most web servers.
Your documentation should also be adjusted to explain that not all servers require chmodding of directories.
Permissions could be explained similar to this
The following files and directories must be writable.
/images ([COLOR=“DarkRed”]this directory would not have to be a recursive chmod if you did not add sample images[/COLOR])
/skins
/var
/var/database
/var/database/backup ([COLOR=“DarkRed”]this directory isn’t needed if controllers/admin/database.php is edited to remove its need[/COLOR])
/var/skins_repository ([COLOR=“DarkRed”]this directory should not have to be writable at all[/COLOR])
/var/snapshots
config.local.php
[quote name=‘Lantan’][QUOTE]—Quote (Originally by S-Combs)—
Please also stop ‘forcing’ these permissions during the archive extraction and also with this coding in config.local.php since this is incorrect for most clients.
PHP:
---------
// Default permissions for newly created files and directories
define(‘DEFAULT_FILE_PERMISSIONS’, 0666);
define(‘DEFAULT_DIR_PERMISSIONS’, 0777);
---------
Thank you
—End Quote—
Do you mean, we should NOT set any permissions on the files that are created during the CS-Cart installation?[/QUOTE][/QUOTE]
Yes exactly… Please do not set permissions because they will not work on all servers…
[quote name=‘Lantan’] what “archive extraction” do you mean[/QUOTE]
The CS-Cart archives downloaded from the client file area extract with the 666/777 permissions already set on the above files/directories. These must all be changed before the cart can be installed on a suPHP server… The above coding in config.local.php must also be edited before the install otherwise the clients cache systems will fail and crash the store because of the incorrect permissions it forces.
[quote]
It is exactly because there can be “different users for PHP and FTP” on a server.
[/quote]
My point was more that the users should not be using FTP method to bring files for upgrade into their store. They should be using http. Having the FTP info on the main page of the settings page makes most customer think they need to enter info when in fact, most don’t. If they use httpd then no one has to open up the security on the file system to account for different users. It’s a user-interface design issue that causes a support problem.
[quote name=‘orangegirl’]connect to your server using some FTP agent
“/public_html” or “/web” or something like that.[/QUOTE]
Connnecting to the server using ftp I see public_html as a sub-directory.
I have entered “public_html” in the upgrade centre as instructed in [URL=“CS-Cart Documentation — CS-Cart 4.15.x documentation”]CS-Cart Documentation — CS-Cart 4.15.x documentation
Should I enter “public_html” or “/public_html” or “/public_html/” ?
Thanks, STeve.
Why are you using FTP for your upgrade?
It is completely unnecessary in almost all cases.
Leave all the FTP fields blank and Save. Then click the “Reload packages” link (or whatever it’s called).
Since you have already done some stuff with FTP, you might have to ask your hosting provider to change the ownerships of all the files and directories in your public_html directory to the appropriate user/group ownerships.
[quote name=‘S-Combs’]Please also stop ‘forcing’ these permissions during the archive extraction and also with this coding in config.local.php since this is incorrect for most clients.
```php
// Default permissions for newly created files and directories
define(‘DEFAULT_FILE_PERMISSIONS’, 0666);
define(‘DEFAULT_DIR_PERMISSIONS’, 0777);
```
Thank you[/QUOTE]
The “forcing” has already been remedied by moving that portion from config.php to config.local.php. The config.local.php is not updated during upgrades (Unless it’s a major upgrade).
That may prevent it from reapplying the incorrect permissions after this code is edited in some cases but it doesn’t fix the problem with new installs and we have to deal with those daily.
[quote name=‘stevethompson’]Connnecting to the server using ftp I see public_html as a sub-directory.
I have entered “public_html” in the upgrade centre as instructed in [URL=“CS-Cart Documentation — CS-Cart 4.15.x documentation”]CS-Cart Documentation — CS-Cart 4.15.x documentation
Should I enter “public_html” or “/public_html” or “/public_html/” ?
Thanks, STeve.[/QUOTE]
Dear Steve,
You should enter “/public_html” in the mentioned field.
And, as it has been told here, you can try upgrading your store without filling in the “FTP server options” fields, but, unfortunately, it will not work on some servers.
[quote name=‘S-Combs’]This is a problem for the client, hosting provider and CS-Cart forum members when a server is running suphp or fcgi. Because, when incorrect permissions are applied, the clients site will break and they will then need to ask for help ‘somewhere’.
[/QUOTE]
[quote name=‘S-Combs’]
suPHP will not allow permisions of 666 or 777 and it will result in 500 errors if these are applied.
[/QUOTE]
Hello S-Combs. Thank you for the clarification. The problem with incorrect permissions on a server running suPHP or FastCGI is clear now.
[quote name=‘S-Combs’]
My solution is simple: Please stop recommending and enforcing these 666/777 permisions because these no longer work on most web servers.
…
Yes exactly… Please do not set permissions because they will not work on all servers…
[/QUOTE]
Thank you for the suggestion. This issue requires deeper study because only after we added the following lines of the code, the number of reported problems connected with incorrect permissions (during installation or upgrade) reduced significantly.
```php
define(‘DEFAULT_FILE_PERMISSIONS’, 0666);
define(‘DEFAULT_DIR_PERMISSIONS’, 0777);
```
Now we receive such support reports very rarely. Taking into account your statement about using only suPHP or FastCGI by most hosting providers, the result should have been opposite. So, we will continue our research. We will contact you if we need your assistance (if you do not mind to help).
[quote name=‘S-Combs’]
Your documentation should also be adjusted to explain that not all servers require chmodding of directories.
[/QUOTE]
I agree. The documentation will be adjusted.
[quote name=‘S-Combs’]
Permissions could be explained similar to this
…
[/QUOTE]
Thank you.
[quote name=‘S-Combs’]
The CS-Cart archives downloaded from the client file area extract with the 666/777 permissions already set on the above files/directories. These must all be changed before the cart can be installed on a suPHP server… The above coding in config.local.php must also be edited before the install otherwise the clients cache systems will fail and crash the store because of the incorrect permissions it forces.
[/QUOTE]
I understand the problems you experience with installing CS-Cart, but I cannot currently promise that the changes you have requested will be made. At least we should offer different options for different types of servers.
At this moment, I recommend to use the ‘–no-same-permissions’ option for extracting the CS-Cart distribution package.
Thank you for your time.
Please, find the instructions about adding the IFRAME support to the Moneybookers payment module in CS-Cart 2.1.4 in the following post:
[url]http://forum.cs-cart.com/showthread.php?p=114160#post114160[/url]
Thank you.
[quote name=‘Lantan’]
Thank you for the suggestion. This issue requires deeper study because only after we added the following lines of the code, the number of reported problems connected with incorrect permissions (during installation or upgrade) reduced significantly.
```php
define(‘DEFAULT_FILE_PERMISSIONS’, 0666);
define(‘DEFAULT_DIR_PERMISSIONS’, 0777);
```
Now we receive such support reports very rarely. Taking into account your statement about using only suPHP or FastCGI by most hosting providers, the result should have been opposite. So, we will continue our research. We will contact you if we need your assistance (if you do not mind to help).
[/QUOTE]
I have already offered my help with Beta server compatibility and MySQL/PHP version testing. Zeke and I exchanged emails concerning this over a year ago. He said he was interested and would get back to me but never did…
Our support tickets have more than tripled since you have been enforcing these permissions and so have permissions related issues posted to this forum. You cannot judge this upon your own support system because you charge for support after a period. This causes many clients to request help from their host or post to this forum first. Since this is such an easy problem to diagnose and repair, you never hear about it on your support desk. Many of our CS-Cart clients have been with us for years and no longer have support credits or wish to pay that additional fee, especially when it turns out to be caused by a problem within the coding.
[quote name=‘Lantan’]I understand the problems you experience with installing CS-Cart, but I cannot currently promise that the changes you have requested will be made. At least we should offer different options for different types of servers.[/QUOTE]
We are by far not the only host having this problem with CS-Cart permissions. Every host running suPHP for improved security is also facing this. Below are just a few examples I found quickly with Google.
[url]http://www.tmdhosting.com/tutorials/cs-cart/cscart-installation.html[/url]
[url]Need an E-Commerce host but Hostgator will not work | Web Hosting Talk
[url]Knowledge Base - Web Hosting Help & Support | Hostgator
Webo issue
[url]http://code.google.com/p/web-optimizator/wiki/InstallingCSCartPlugin[/url]
This is a very big problem so please study suPHP since most hosts are now running it. suPHP is also now set by default in most new VPS and Dedicated server offerings by most providers.
[quote name=‘Lantan’]I recommend to use the ‘–no-same-permissions’ option for extracting the CS-Cart distribution package.[/QUOTE]
This does work with the .tgz archive but only for users with shell access. The majority of users do not have SSH access so either, upload the extracted files manually or rely on the file manager in their control panel (cPanel for instance) to upload and extract archives and that will retain the existing archive permissions with both the .zip and .tgz files…
I’m not complaining but, I would really like to see your company take more interest in the server configurations your product will be hosted on because it would make everyone’s life easier and also produce a much more stable product.
Thank you for your attention to this Alex …
Alex,
If during the installation initialization you would simply get the permissions of the install directory (I.e. ‘.’) that would tell you what kind of permissions you need to use. I.e. if ‘.’ is 755, use 755/644. If it is 750 then use 750/640, etc… Pretty simple and pretty dynamic. You can then set the default in config.local.php appropriately based on information rather than guessing.
[quote name=‘tbirnseth’]Alex,
If during the installation initialization you would simply get the permissions of the install directory (I.e. ‘.’) that would tell you what kind of permissions you need to use. I.e. if ‘.’ is 755, use 755/644. If it is 750 then use 750/640, etc… Pretty simple and pretty dynamic. You can then set the default in config.local.php appropriately based on information rather than guessing.[/QUOTE]
I like this idea, appears to be a simple & straight forward approach to dealing with the problem! After every upgrade I have had to go back & re-check every directory & file in our CS-Cart installation to see if any permissions were changed from our default of 755/644 and make any needed corrections. Of course many users do not do this and I am quite certain this is one of the main issues why people experience so many problems after they upgrade which are often posted here in the forums.
Personally I think the biggest help for this would be to move the FTP info to a separate tab with a note that says “Only set these settings if the standard http method of upgrading has failed.”.
I see your point and believe that would help reduce upgrade issues as well for many. Personally, I have only ever used the http method during upgrade and have always left the ftp details as blank.
I was more focused on preventing the permissions from deviating from what are currently being used on individual sites. I suppose what frequently happens is that for users of which 777/666 permissions were already in place, then for those particular users the default permissions for newly created directories/files within config.local.php is fine. However, for any of us using more secured settings then when any new directories/files are created during the upgrade we end up with permissions errors which may not be immediately evident until those particular directory/files are called for? Obviously there are alot of directories & files within CS-Cart so it is quite easy to overlook the permissions settings on each & every one of them, especially when one is not aware that what you choose to be as default could very well have not been followed after an upgrade. 
Reading ‘.’ and applying the derived permissions would then only require a site owner to manage the permissions on the root folder that cs-cart is to be installed in.
Hello,
I would like to thank everyone who suggested a solution in this forum regarding the permission issue on servers with suPHP. We will investigate it deeper.
[quote name=‘S-Combs’]I have already offered my help with Beta server compatibility and MySQL/PHP version testing. Zeke and I exchanged emails concerning this over a year ago. He said he was interested and would get back to me but never did…
[/QUOTE]
We set up our own test servers after Zeke contacted you last year. We are sorry for not notifying you about it.
[quote name=‘tbirnseth’]
If during the installation initialization you would simply get the permissions of the install directory (I.e. ‘.’) that would tell you what kind of permissions you need to use. I.e. if ‘.’ is 755, use 755/644. If it is 750 then use 750/640, etc… Pretty simple and pretty dynamic. You can then set the default in config.local.php appropriately based on information rather than guessing.[/QUOTE]
Yes, it is a brilliant idea. Thank you Tony. Though it does not resolve the second part of the issue concerned with the file/directory permissions after extracting the CS-Cart distribution package.
Please note we would like to find a solution that will work in most (ideally, all) cases without the necessity to change the file/directory permissions manually:
- after extracting the CS-Cart distribution package and before installing it.
- before upgrading CS-Cart.
Thank you.
At the point before you check for write permissions on config.php and whatever else you do in the installer (I’ve not looked), offer to traverse the directory and set the appropriate permissions based on the root of the store.
There’s not going to be anything you can do about ownerships other than making sure your archives are packaged with owner/group nobody/nobody when you create them. If the user uses Cpanel to extract, then the hosting setup should take care of it. If they use SSH, you should assume they know enough to do it correctly.
Side note: Since this comes up a lot, in core/fn.fs.php in the fn_mkdir() function, you should change it to be something like:
if( !mkdir($path, $perms) )
trigger_error(__FUNCTION__.": mkdir($path, $perms) failed");
I think it will cut down the support issues because the user will now know what path failed and can use their own head to go fix things up.
[quote name=‘tbirnseth’]set the appropriate permissions based on the root of the store.[/quote]
This wont work properly with many servers because the docroot has different permissions and ownerships than what should be within it.
cPanel and Plesk servers for example use the following
cPanel
Doc root: public_html
Owner: Username
Group: nobody
Permissions: 750
Directories within the Doc root require default permissions of 755 and ownerships of (depends on PHP handler). Can be user/user, nobody/nobody or a variation. (nobody is the name of the apache service and may be different on some servers)
Plesk
Doc root: httpdocs and httpsdocs
Owner: Username
Group: psaserv
Permissions: 750
Directories within the Doc root require default permissions of 755 and ownerships of username/pcacln
Interspire shopping cart has a function that will test file and directory permissions then suggests the appropriate changes to make. I think that would be best also for CS-Cart instead of trying to change the permissions because, there are just too many different server configurations and also security limitations.