Difference between revisions of "CcHost File Access"

From Creative Commons
Jump to: navigation, search
(3.1 update)
(What ccHost Requires (IMPORTANT))
 
(11 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 13: Line 19:
 
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 probably 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. However, depending on whether you run PHP  
+
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.
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 48: Line 51:
 
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 3.1 installations and later: during installation you specified a name for your custom files. Under that directory the installer created a 'temp' directory that will need to be accessed by ccHost scripts.  
+
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.  
  
For installations previous to 3.1: In order to install properly, 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. The '''people''' directory is normally created by ccHost the first time something 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.
+
{{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 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 ccHost policy section because none of  
 
 
this applies to your ccHost installation.
 
this applies to your ccHost installation.
  
Line 77: Line 75:
 
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 103: 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 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.'
+
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.