Make caching engine use correct permissions on shared linux hosting

[Chris_C]

Many other popular PHP web application frameworks - Joomla, Drupal, Wordpress - have caching engines that use correct permissions on shared linux hosting.

Could the Sugar development team - in the SF Bay Area - make the Sugar caching engine use correct permissions - and finally get Sugar to run correctly out-of-the-box on shared linux hosting ??

[jmertic]

Many other popular PHP web application frameworks - Joomla, Drupal, Wordpress - have caching engines that use correct permissions on shared linux hosting.

Could the Sugar development team - in the SF Bay Area - make the Sugar caching engine use correct permissions - and finally get Sugar to run correctly out-of-the-box on shared linux hosting ??

Could you detail more where the permissions problems are, as in what's getting set with the wrong permissions and how should they be set instead?

[Chris_C]

Could you detail more where the permissions problems are, as in what's getting set with the wrong permissions and how should they be set instead?

This is my first reply - I will follow up later with more details.

From the official documentation for 6.3.0:
Sugar Community Edition Documentation | Open Source Business & Social CRM - SugarCRM

At the absolute bottom of the page:

Configuring Default Permissions for Sugar Files on Linux
If you are running Sugar on Linux platform, you can control ownership and accessibility to all Sugar files and folders by configuring default user and group permissions.
The following is an example of setting Read, Write, and Execute permissions for the Apache user and the Apache group on Centos operating system:
'default_permissions' => array(
'dir_mode' => 02770,
'file_mode' => 0660,
'chown' => 'apache',
'chgrp' => 'apache', ),
For dir_mode, you may see a value of 1528, which is the decimal equivalent of the octal value 02770. For file_mode you may see a value of 432 which is the decimal equivalent of octal value 0660.

I installed on Centos linux/apache/mysql shared hosting, and the Sugar installer generated this inside config.php:

'default_permissions' =>
array (
'dir_mode' => 1528,
'file_mode' => 432,
'user' => '',
'group' => '',
),

The user and the group are empty as you can see - this causes serious errors.

The result of this is - and you can see dozens of posts on this forum - and probably thousands more who didn't bother posting. Newbie users are getting severe http errors while viewing Sugar for the first run - inaccessible css and javascript (?!) - many first time Sugar users have posted, asking for help, saying "css looks messed up after clean install?" I wouldn't be surprised if 1000x more new users have encountered this problem, and simply given up on Sugar entirely and went over to the competition. It's that serious, and should be fixed.

I posted a PHP script on this forum, allows a user to *temporarily* gets around this permissions problem by setting all Sugar files to 644 and folders to 755 - "miraculous," "amazing," "this should be included with sugar," are some of the comments I received. Some had been frustrated for many days and didn't believe it could be that - after all they right-clicked on the cache folder and 3 others and set it to 755 but it still failed to work - but they were ecstatic to try my PHP script and find it fixed their issue.

But the problem comes back - gradually over time - as the cache engine generates more new files - as it does - but sets the wrong permissions/ownership. When the user goes to access those cached page elements - their browser will be unable to get the file, denied access due to permissions/ownership - when it's a css or js, so the browser ends up rendering the page horribly - unusable - since it's missing some vital js and css.

Sugar CE should install on linux shared hosting and just work, out of the box- like popular PHP web application Wordpress, Joomla, and Drupal run without showstopper permissions issues, on hundreds of millions of internet sites. The Sugar installer code can and should detect it's running on linux, detect the apache user and group, and automatically plug these values into the default permissions section of the config.php.

[Chris_C]

Post 2 of ? - Follow up on the permissions / owner/ group on shared linux hosting :

The upgrade wizard was consistently failing with owner and group set to 'apache' 'apache'.

The error message was "unable to create temp folder".

Even running my fix-permissions.php script wasn't giving any joy.

When I changed the owner and group back to '' and '' - the upgrade wizard finally worked perfectly.

Upgraded to 6.4.0RC3.



NOTE: This was while using Angel's "wizard-less uploads" method - which simply skips the upload step 1 by placing the zip and manifest in their expected locations - so the upgrade wizard starts at step 2.

I had reverted to Angel's wizard-less uploads method because upgrades were failing due to flaky behavior - permissions and ownership suspected as the cause. And indeed they were.
Angel's Blog: SugarCRM Tips: Wizard-Less Uploads

[jmertic]

Can you be sure to file a bug for this at SugarCRM Bug Tracker | Open Source Business & Social CRM - SugarCRM with all the notes above in it. This is great feedback, and I want to be sure to capture it and bring it back into Engineering.

Thanks!

[selfmade64856]

I am having a similar problem. After creating a Campaign Schedule which is then completed at the specific scheduled time, once the campaign is sent out if I now click on the "View Status" of the campaign I get an incomplete status page and sugar throws me an error popup which is shown here:



What I have to do to fix this is open my ftp client, navigate to the cache folder and then recursively change all of the cached files to 664. Once I complete this step everything works and looks the way it is supposed to which is shown here:



I spoke with my host and they said:

"Unfortunately this is not a server-side problem, PHP scripts should be changed to save files with the correct permissions.
Alternatively you can set up a cron job which will run once a day and change permissions as needed.
Cron job command should be similar to this:

chmod -R 664 /home/sitesire/public_html/crm/cache/"

So my question is, what do I need to do to get SugarCRM to create these newly cached files with the correct file permissions without having to run another cron job? Thanks.

[Chris_C]

So my question is, what do I need to do to get SugarCRM to create these newly cached files with the correct file permissions without having to run another cron job? Thanks.

John Mertic, selfmade64856,


I dug into this permissions bug, in the code, on the forum, on the web, in the official Sugar docs, and in the Sugar KB.

So far, this is what I've uncovered, including reasons why it works like that.

I'm close to having a solution... almost.


There's a setting in config.php (this holds all the basic configuration data for your Sugar instance, and is located in the root of your Sugar install).

This setting controls the default permissions AND ownership, that Sugar will use when creating folders and files (such as the cache files - which Sugar's constantly creating - as it should).

The part of Sugar's config.php that we have to modify, looks like this, out of the box, on a fresh Sugar 6.3 instance, on a shared linux (RHEL/CentOS 5) server:

  'default_permissions' => 
  array (
    'dir_mode' => 1528,
    'file_mode' => 432,
    'user' => '',
    'group' => '',
  ),

As you can clearly see, out of the box Sugar is setting files and folders like so:
a) Directory permissions to 1528 decimal, or octal 02770, or rwxrws---.
b) File permissions of 432 decimal, or octal 0660, or rw-rw----.
c) GUID on,
d) User owner and Group owner to nothing.
(A link to a good explanation of the general meaning of linux permissions and ownership, if you're scratching your head wondering what on earth this is:
Linux permissions )

The reason Sugar's defaults are no good for linux shared hosts, is because, for high security reasons:
1) the username that the apache process runs under (apache, www-data, www, or nobody) is a different username from your shared hosting account username, and
2) this "apache user" MAY belong to a different GROUP than your actual shared hosting account user's GROUP.

While you use Sugar, browse/create/update records, go from page to page, Sugar constantly generates cache files - stores them in the cache folder, and creates other files, storing them elsewhere in the folders under your Sugar instance's document root.

For example - when you upload your custom company logo, during the Sugar install - it saves your GIF on the linux shared host's filesystem, in an uploads folder somewhere under the Sugar document root.
This file has the wrong permissions and ownership, so apache cannot serve it to your browser!
When Sugar goes to show you your logo on the next screen, in place of the log is a big empty box with the symbol for "broken link" showing instead of the image. (!!!)

Same, very serious, problem for business Documents that you upload to Sugar, to associate with Sugar Accounts and Opportunities.
The uploaded Documents get saved with the wrong default permissions, and are inaccessible by your browser - at least until the permissions are fixed somehow !!
But fixing the permissions like this, even with a cron job script, is a less than ideal workaround:
a) because you can't be running the script ever minute - that's a crazy waste of disk IO - and
b) you're usually going to want to use your uploaded file within seconds, not up to a minute later..

Due to incorrect (for the shared linux hosting environment) permissions and/or ownership, users suffer from Sugar messing up the pages, and experiencing inappropriate, unexpected error messages - for example, the popup that says "undefined" instead of "loading", or css, javascript, and images that fail to load at all - making the page practically unusable.

I haven't completed the analysis of this - as of this moment - let alone gotten the full solution to it.

My script fix-permissions.php (attached below - to run it, put it in the root of your sugar instance and run it by entering the URL to the script in your browser) fixes this temporarily by recursively setting all directories to 755 (rwxr-xr-x) and all files to 644 (rw-r--r--). These are popular, standard, middle of the road, security permissions, that work reliably well on a public facing website hosted on centos linux.

More to come...

Chris

[Chris_C]

Can you be sure to file a bug for this at SugarCRM Bug Tracker | Open Source Business & Social CRM - SugarCRM with all the notes above in it. This is great feedback, and I want to be sure to capture it and bring it back into Engineering.

Thanks!

John,

As you requested, I posted this feature request on the Sugar Bug Tracker. Here is the link:

SugarCRM Bug Tracker | Open Source Business & Social CRM - SugarCRM

Chris

[selfmade64856]

John Mertic, selfmade64856,
My script fix-permissions.php (attached below - to run it, put it in the root of your sugar instance and run it by entering the URL to the script in your browser)

Hi Chris, tired your fix but only received this error when opening the script in my browser:

"Fixing SugarCRM File Permissions...

mode of `./config.php' retained as 0644 (rw-r--r--)

Warning: _system() [function.-system]: Permission Denied in /home/360tours/public_html/crm/fix-permissions.php on line 37

Warning: _system() [function.-system]: Permission Denied in /home/360tours/public_html/crm/fix-permissions.php on line 38

Warning: _system() [function.-system]: Permission Denied in /home/360tours/public_html/crm/fix-permissions.php on line 39

Warning: _system() [function.-system]: Permission Denied in /home/360tours/public_html/crm/fix-permissions.php on line 40

Fixing SugarCRM Directory Permissions...

Warning: _system() [function.-system]: Permission Denied in /home/360tours/public_html/crm/fix-permissions.php on line 46

Warning: _system() [function.-system]: Permission Denied in /home/360tours/public_html/crm/fix-permissions.php on line 47

Warning: _system() [function.-system]: Permission Denied in /home/360tours/public_html/crm/fix-permissions.php on line 48

Warning: _system() [function.-system]: Permission Denied in /home/360tours/public_html/crm/fix-permissions.php on line 49"

That was it. Any ideas?

Thanks!!

[Chris_C]

Hi Chris, tired your fix but only received this error when opening the script in my browser:

"Fixing SugarCRM File Permissions...

mode of `./config.php' retained as 0644 (rw-r--r--)

Warning: _system() [function.-system]: Permission Denied in /home/360tours/public_html/crm/fix-permissions.php on line 37

Fixing SugarCRM Directory Permissions...

Warning: _system() [function.-system]: Permission Denied in /home/360tours/public_html/crm/fix-permissions.php on line 49"

That was it. Any ideas?

Thanks!!

Your shared hosting provider is denying use of the system() PHP function - security reasons.

I'll attach a version 2 of the fix-permissions that will work.

By the way, which shared hosting company are you using?