Difference between revisions of "CcHost File Access"

From Creative Commons
Jump to: navigation, search
 
(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''' who owns the directory
+
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</b> wgroup  4096 Jul 15 01:41 cctools
+
drwxrwxr-x  5 victor wgroup  4096 Jul 15 01:41 icons
drwxrwxr-x  5 nobody</b> wgroup  4096 Jul 17 02:09 contests
+
drwxrwxr-x  5 nobody wgroup  4096 Jul 17 02:09 content
 
</pre>
 
</pre>
  
The first directory 'cctools' created by me during FTP install. The second directory 'contests' was created by ccHost when I said 'Create Contest' and is therefore owned by another user.
+
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 all cases: In order to install properly,
+
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.  
ccHost (or more precisely
 
the PHP account ccHost is running as) must have write permissions in
 
the root directory of the ccHost installation, in a directory under it called
 
cclib/phptal/phptal_cache''' and where ever you told the installation to
 
put log files to. Specifically and in UNIX parlance this means
 
full permission: Read, Write and Execute.
 
  
NOTE: The people''' directory is normally created by ccHost the first time something
+
{{Infobox|NOTE: Your installation will not work properly until local_files and and directories under it are writable to script.}}
is uploaded and the contests''' directory is normally created the first time something is
 
uploaded into a contest. If these directories already exist then ccHost will only need permissions
 
in them, cclib/phptal/phptal_cache''' and your logfile directory -- not the root. Instructions
 
for how to set these up (and whether you even have to) are covered below.  
 
  
 
=== 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</b> as your login 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 <a href="#policy">ccHost policy section</a> because none of  
 
 
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'''. You can see in the listing first mentioned  
+
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</b> 4096 ....
+
drwxrwxr-x  5 victor wgroup  4096 ....
drwxrwxr-x  5 nobody wgroup</b> 4096 ....
+
drwxrwxr-x  5 nobody wgroup  4096 ....
 
</pre>
 
</pre>
This is important because while you may not be the same user''' as
+
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
+
the PHP account, UNIX has another level of security called group before
getting to the global''' space (the rest of the world).
+
getting to the global space (the rest of the world).
If this is the case then you should be good to go, because the default
+
If this is the case then you should consider restricting the directories that need writing access to only owner and group.
behavior of ccHost is to create directories and files with write access to  
+
 
anyone in the same group as ccHost.
+
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 these three directories  
 
available for writing to global''' users (a.k.a. other''').
 
The parameter to chmod'''
 
is o''' for other''' (the letter o, not the number zero) :
 
<pre>
 
mkdir contests
 
chmod o+rwx contests
 
mkdir people
 
chmod o+rwx people
 
chmod o+rwx cclib/phptal/phptal_cache
 
</pre>
 
At this point any user logged into your server with any user account
 
in any user group can write, delete, create directories, etc. in the
 
people''' and contests''' directories where your and your
 
user's files live.
 
 
 
One possible work-around is to have a browser initiated PHP
 
script temporarily set global access rights to write (using the PHP command chmod()) to
 
the ccHost tree. Now your
 
user account will have write access via a shell or FTP to change files in the system. After
 
your changes to the ccHost directories and files are complete you can run another browser initiated
 
PHP script to disable global access again.
 
 
 
The ccTools teams does not provide these kinds of scripts at this time.
 
  
 
== 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

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.