How to install on a shared host?

[gearloss]

Let's assume I want to install CMSMS on a shared webhost at Pair Networks (www.pair.com).

That is a typical FreeBSD account on a machine you share with some 50-100 other users (who you don't know and can't trust).

In this kind of environment you want the following file permissions:

755 (user: rwx, group: r-x, other: r-x) for directories.
644 (user: rw-, group: r--, other: r--) for most files.
600 (user: rw-, group: ---, other: ---) for files with "secrets" like passwords and such.

User - the 'user' group consists only of the owner of the file (your account, in most cases)
Group - the 'group' group consists of the other users on the server
Other - the 'other' group consists of everyone else -- most importantly, the web server falls into the 'other' category.

The risks of not paying attention to file permissions on a shared host are very real:

• Other users can read your database passwords etc. if you leave the config.php file with read-access for 'group' or 'other'.
• Other users can erase files and write stuff into your web-directories if you open for write access for 'group' or 'other'.

This means you need to trick the webserver in a way that it will access files as 'user'. Since you can't fiddle with these things on a shared host (you are not root), there has to be another way to do it. At Pair Networks the trick is to use a system CGI called "php-cgiwrap". See explanation here if you want the details:

  http://www.pair.com/support/knowledge_b ... iwrap.html

This requires a small change to the .htacess file, to insert a few lines like this:

  Action application/x-pair-sphp4 /cgi-sys/php-cgiwrap/username/php4.cgi/users/
  AddType application/x-pair-sphp4 .php
  AddType application/x-pair-sphp4 .htm
  AddType application/x-pair-sphp4 .html

This will allow the webserver to access files as 'user' when parsing these filetypes through PHP.

Now the question is: What exactly do you have to do, in order to get CMSMS set up for this kind of environment? What are the important settings?

How about the modules? Like file permissions on Captcha (my 0.3 install creates rw-/---/--- files, which the webserver can't read from).

What files contains "secrets" that we don't want other users to see? config.php is obvious - but what else?

Running all php files as "user" adds another risk - if some of all that php code can be exploited.

Your comments and suggestions are much appreciated.

I tried a similar question here, but didn't get any response - hence the modified repost:
http://forum.cmsmadesimple.org/index.ph ... 308.0.html

[cnymike]

I use Pair.com as my host and I've  just setup php-cgiwrap to eliminate the need to have world-writable directories.

But now I'm getting errors showing up at the bottom of the Admin page...

Code: Select all

Warning: Unknown(): open(/tmp/sess_1fa87d412e696d3ba03d63da0826e8da, O_RDWR) failed: Permission denied (13) in Unknown on line 0

Warning: Unknown(): Failed to write session data (files). Please verify that the current setting of session.save_path is correct (/tmp) in Unknown on line 0

I do not know what these mean or how to fix the problem. Can some help?

Michael

UPDATE

I  just went into Admin and now on the Pages screen I get these errors...

Code: Select all

Warning: fopen(/usr/www/users/xxxxx/xxxxx/tmp/cache/contentcache.php): failed to open stream: Permission denied in /usr/www/users/xxxxx/xxxxx/lib/classes/class.contentoperations.inc.php on line 557

Warning: fwrite(): supplied argument is not a valid stream resource in /usr/www/users/xxxxx/xxxxx/lib/classes/class.contentoperations.inc.php on line 558

Warning: fclose(): supplied argument is not a valid stream resource in /usr/www/users/xxxxx/xxxxx/lib/classes/class.contentoperations.inc.php on line 559
Current Pages

The above referenced code block looks like this...

Code: Select all

		if (!$loadedcache && $usecache)
		{
			debug_buffer("Serializing...");
			$handle = fopen($cachefilename, "w");
			fwrite($handle, '<?php return; ?>'.serialize($tree));
			fclose($handle);
		}

Don't have a clue how to fix this.

[Pierre M.]

Some places, like the cache, need to be writable.
I don't know about "pair", but the installation instructions provide file access rights settings that work with other hosters.
Pierre M.

[cnymike]

I didn't have these errors until I installed phhp-cgiwrap today.

Are you saying that /tmp/cache needs to be writable? If that's what you mean, I just looked and it has 777 permissions right now. then there is /tmp/cache/contentcacge.php which has 640 permissions. Is that the file that needs to have different permissions? That file is owned by "nobody".

[Pierre M.]

I didn't have these errors until I installed phhp-cgiwrap today.

Good hint to the source of the problem. It doesn't seem to be CMSms related.

Are you saying that /tmp/cache needs to be writable? If that's what you mean, I just looked and it has 777 permissions right now.

Looks good.

then there is /tmp/cache/contentcacge.php which has 640 permissions. Is that the file that needs to have different permissions? That file is owned by "nobody".

I don't know about CMSms internals, but I find it strange to have .php file in the cache. Isn't this injected code ? Or just the Smarty templating mechanism ?
Try to clear you cache in admin.
Pierre M.

[cnymike]

It seems that the problem was that the contentcache.php fle was owned by 'nobody'. I called the host and had them change ownership to my username and once that was done, those errors in admin went away.

Apparently once cgiwrap was installed, the ownership of files by "nobody" was screwing things up.

So why is there a php file in the tmp/cache ? I hope it's not injected.

[Pierre M.]

...cgiwrap was installed, ...screwing things up.

May be there are answers in its own documentation, not CMSms'.
Try to clear the cache, erase all files in tmp/cache (after having backed them up, of course). If CMSms still works (surf all your pages, work in the admin too), you know you don't need these .php files in cache.
Back up and tries, a good way to get specialized answers for your hosting location.
Pierre M.