Difference between revisions of "CcHost File Access"
Fourstones (talk | contribs) |
Fourstones (talk | contribs) (→What ccHost Requires (IMPORTANT)) |
||
(22 intermediate revisions by 3 users not shown) | |||
Line 1: | Line 1: | ||
+ | [[Category:ccHost]] | ||
+ | [[Category:ccMixter]] | ||
+ | [[Category:Developer]] | ||
+ | [[Category:Software]] | ||
+ | [[Category:Technology]] | ||
+ | {{cchost_head}} | ||
+ | {{lowercase}} | ||
== Information regarding UNIX file permission and ccHost== | == Information regarding UNIX file permission and ccHost== | ||
− | Setting file permissions in the most efficient and secure way can be tricky with | + | 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. |
− | 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 | There are many (i.e. many, many) UNIX configurations for running Apache and PHP | ||
Line 12: | Line 18: | ||
If you 'own' the server and have super-user (root) access then these problems | If you 'own' the server and have super-user (root) access then these problems | ||
− | are moot because you have the rights to do whatever you want with the | + | are probably moot because you have the rights to do whatever you want with the |
− | directories and files created by ccHost. | + | 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 | + | 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 |
− | 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. | access rights and that's where the issues begin. | ||
Line 38: | Line 42: | ||
server administrator has set up all PHP applications like ccHost | server administrator has set up all PHP applications like ccHost | ||
to run, not as you, but as a special user, usually called 'nobody' | to run, not as you, but as a special user, usually called 'nobody' | ||
− | and UNIX considers 'nobody' to be the user | + | and UNIX considers 'nobody' to be the user who owns the directory |
and files. | and files. | ||
The main point is: These are two very distinctly different identities and the directories | 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. | + | 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 | Evidence can be seen when you list out the directories in your ccHost | ||
installation: | installation: | ||
<pre> | <pre> | ||
− | drwxrwxr-x 5 victor | + | drwxrwxr-x 5 victor wgroup 4096 Jul 15 01:41 icons |
− | drwxrwxr-x 5 nobody | + | drwxrwxr-x 5 nobody wgroup 4096 Jul 17 02:09 content |
</pre> | </pre> | ||
− | The first directory ' | + | 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)=== | === What ccHost Requires (IMPORTANT)=== | ||
− | For | + | 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. |
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | NOTE: | + | {{Infobox|NOTE: Your installation will not work properly until local_files and and directories under it are writable to script.}} |
− | |||
− | |||
− | |||
− | |||
=== Case 1: You and ccHost are the same user=== | === Case 1: You and ccHost are the same user=== | ||
In the best case scenario, some web hosters make all of this go away by | In the best case scenario, some web hosters make all of this go away by | ||
− | simply having PHP applications run under the same account | + | 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 |
− | 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 | ||
this applies to your ccHost installation. | this applies to your ccHost installation. | ||
Line 83: | Line 72: | ||
The next question you have to ask is whether your account and PHP account | The next question you have to ask is whether your account and PHP account | ||
− | is in the same group | + | is in the same group. You can see in the listing first mentioned |
above that this is case: | above that this is case: | ||
<pre> | <pre> | ||
− | drwxrwxr-x 5 victor wgroup | + | drwxrwxr-x 5 victor wgroup 4096 .... |
− | drwxrwxr-x 5 nobody wgroup | + | drwxrwxr-x 5 nobody wgroup 4096 .... |
</pre> | </pre> | ||
− | This is important because while you may not be the same user | + | This is important because while you may not be the same user as |
− | the PHP account, UNIX has another level of security called group | + | the PHP account, UNIX has another level of security called group before |
− | getting to the global | + | getting to the global space (the rest of the world). |
− | If this is the case then you should | + | 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=== | === Case 3: You and ccHost are not in the same group=== | ||
− | If your login account and your PHP account are not even in the | + | If your personal UNIX login account and your PHP account are not even in the |
same group then you may still have an out: | same group then you may still have an out: | ||
Line 112: | Line 111: | ||
you can make the needed change. | you can make the needed change. | ||
− | If your login account and your PHP account are not in the | + | 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. |
− | 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 | ||
− | available for writing to global | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | the ccHost | ||
− | |||
− | |||
− | |||
− | |||
− | |||
== ccHost Permissions Policy== | == ccHost Permissions Policy== | ||
− | ccHost 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. | + | 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. |
Latest revision as of 20:13, 3 May 2009
Docs Home | Install | Upgrade | Troubleshoot | Customize | Admins | Devs | Content | Query | Templates | Commands | Skins |
Contents
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.
NOTE: Your installation will not work properly until local_files and and directories under it are writable to script.
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.