Difference between revisions of "CcHost File Access"
(→ccHost Permissions Policy)
|Line 1:||Line 1:|
== Information regarding UNIX file permission and ccHost==
== Information regarding UNIX file permission and ccHost==
Revision as of 20:12, 3 May 2009
Information regarding UNIX file permission and ccHost
Setting file permissions in the most efficient and secure way can be tricky with a content management system such as ccHost on a UNIX system.
There are many (i.e. many, many) UNIX configurations for running Apache and PHP and this document does not pretend to cover all. It is a compendium of issues encountered by various ccHost installations under some popular scenarios. If there are security issues on your server with ccHost or you would like to avoid them, hopefully this document will arm you with enough information to ask your system administrator the right questions.
If you 'own' the server and have super-user (root) access then these problems are probably moot because you have the rights to do whatever you want with the directories and files created by ccHost. However, depending on whether you run PHP in CGI mode or not, these issues could very well be a big problem.
On the other hand if you are using a company server or a web hosting service, especially on a 'shared server', then chances are you do not have such access rights and that's where the issues begin.
In either case the thing to understand is that on a UNIX system: Whoever creates a file or directory on UNIX typically has full (or enough) access rights to that file or directory to do what ever they like.
You are not nobody
When you sign on to your web server via a terminal application (i.e. shell) or transfer files via FTP you are operating as whoever you logged in as. When you copy the ccHost installation onto your server (or unzip them directly there) the directories you create and files you copy into them are under your jurisdiction and UNIX considers you the 'user' (you 'own' them).
When ccHost is running on a UNIX server it is considered a PHP browser application running in an instance of Apache. Your server administrator has set up all PHP applications like ccHost to run, not as you, but as a special user, usually called 'nobody' and UNIX considers 'nobody' to be the user who owns the directory and files.
The main point is: These are two very distinctly different identities and the directories and files created by ccHost are owned by this 'nobody' account, not you.
Evidence can be seen when you list out the directories in your ccHost installation:
drwxrwxr-x 5 victor wgroup 4096 Jul 15 01:41 icons drwxrwxr-x 5 nobody wgroup 4096 Jul 17 02:09 content
The first directory 'icons' created by me during FTP install. The second directory 'content' was created by ccHost when I installed ccHost and is therefore owned by another user.
What ccHost Requires (IMPORTANT)
For 3.1 installations and later: The path configuration screen (admin/paths) will let you know exactly which directories require write access from script. These include 'content' and your 'local_files' directory.
Case 1: You and ccHost are the same user
In the best case scenario, some web hosters make all of this go away by simply having PHP applications run under the same account as your login account. There is no 'nobody' account to contend with and ccHost is, in fact, running as you so permission to create directories in the main directory or write files to the phptal_cache directory is given. So if you ask your system administrator 'Do PHP apps run under my user's account?' and if the answer is 'Yes' then you can skip down the ccHost policy section because none of this applies to your ccHost installation.
Case 2: You and ccHost are in the same group
The next question you have to ask is whether your account and PHP account is in the same group. You can see in the listing first mentioned above that this is case:
drwxrwxr-x 5 victor wgroup 4096 .... drwxrwxr-x 5 nobody wgroup 4096 ....
This is important because while you may not be the same user as the PHP account, UNIX has another level of security called group before getting to the global space (the rest of the world). If this is the case then you should consider restricting the directories that need writing access to only owner and group.
The way to traditionally do this is to run the chmod command as such:
chmod 775 folder
Or, for all files under the folder recursively:
chmod -R 775 folder
And/or, just to give the group full read (r), write (w) and execute (x) privileges:
chmod -R g+rwx folder
Case 3: You and ccHost are not in the same group
If your personal UNIX login account and your PHP account are not even in the same group then you may still have an out:
Some web hosting companies provide you with a secure browser based interface that allows you to bridge difference in user rights by giving you behind-the-scenes circumvention to ownership issues in your space on the server. When the ccHost documentation prescribes things like 'setting write permissions on a directory' you should use this secure web interface provided by your web hoster to perform the action. When you need to make changes to the files, use this interface. That way it won't matter if the 'nobody' account or your account created the directory or file, you can make the needed change.
If your personal UNIX login account and your PHP account are not in the same group and you haven't a secure web interface, then your system administrator or web hosting service has left you with no choice to make the necessary directories available for writing to global users (a.k.a. other). You should keep the ccHost default access permission at 777.
ccHost Permissions Policy
ccHost 3.0 will use 0777 as the default for creating files. This is so new installations can get quickly off the ground and running. If you wish to change this policy go to 'Manage Site' and then 'Global Settings' or browse to the admin/setup command.