File permissions - cgi etc

As a complete Unix newbie who's just been given the keys to a virtual server, I'm confused by file permissions for cgi scripts.  Having set up my cgi-bin directory and uploaded some scripts, I can't work out which chmod setting to give them.  And how do I prevent access to the directory while still permitting the right level of access to the scripts?  Can I just password protect the directory using the .htaccess file, or will that prevent access to the script functions?  I've been given several conflicting opinions on this, so I need an answer that is guaranteed to work (ideally one that someone can show me is working on their own server).
Who is Participating?
turnkeyConnect With a Mentor Commented:

Great, the Apache webserver is the most widely used on unix operating systems.  The Apache webserver is usually run as user "nobody" and group "nobody" (this is the default and is configured by the httpd.conf file located in /usr/local/etc/httpd directory).  Below is a step-by-step outline on configuring your directories, files, cgi's, etc. to get everything working properly.  You do not need to password protect the cgi-bin directory (with .htaccess and .htpasswd directives) because Apache forbids browsing access within the directory by default.

Enter the commands into your system EXACTLY as I have listed below (without the # prompts, of course) and hit <RETURN> after each command.  You need enter these commands as the root user.  

Alright...Here we go:

1).  Change to the polemic directory by typing the following:
     #cd /usr/local/etc/httpd/htdocs/polemic

2).  Change permissions on the sub-directories by typing:
     #chmod 755 *

3).  Change permissions on the "." and ".." dirs by typing:
     #chmod 755 .
     #chmod 755 ..

4).  Change to the cgi-bin directory by typing:
     #cd cgi-bin

5).  Change permissions on the files in the cgi-bin by typing:
     #chmod 755 *

6).  Change group/owner of your cgi scripts to nobody/nobody.
     Doing this ensures that the Apache web server (which, as
     mentioned above, runs as user "nobody" and is a member if
     the group "nobody") is the only user that is actually given
     full access to the cgi scripts.  You should substitute
     "my.cgi" with the actual name of your cgi script file.
     Repeat the commands for each additional cgi script that you
     have currently or after you install any new scripts
     (e.g. mailform.cgi, polling.cgi, chat.cgi)
     #chown nobody:nobody my.cgi
     #chmod 755 my.cgi

7).  Just to be sure, let's verify that your htdocs files are
     also set to the correct permissions.  Type:
     #cd /usr/local/etc/httpd/htdocs/polemic/htdocs
     #chmod 755 .
     #chmod 755 ..
     #chmod 666 *

8).  O.K., that's everything.  Basically, what we've done is ensured that the cgi's can only be manipulated by the user nobody.  The scripts will interact with other binaries as written without problem.  You should now re-start the Apache web server so that the changes in permissions are seen by Apache.

If you have any questions or problems, please let me know ASAP.

For scripts that have to run you can give permissions like this:
711  read, write an execute for the owner and execute for th rest of the world.

511 read for the owner of the script an execute for the rest of the world.

111 execute for everybody, no read or write permission.

Now, to block access to the directory (understanding access like the possibility to modify things in the directory) youc can change the permissions of the cgi-bin directory to:

755 that is owner can modify, but the rest of the world can change to the diretory but cannot modify anything inside the dircetory.

You can use these numeric values for chown or the equivalent letter codes.

PolemicAuthor Commented:

Okay, so which permission, specifically, should I use for:

- form to mail
- polling
- www board
- html chat
- visitor logging

and similar scripts?  Is making them only executable for the rest of the world (711) okay?  What if the script in some way needs to  create or update files?  I was told they'd then have to be 777.

755 seems to be the general consensus for the directory, but I'm getting conflicting advice for the scripts themselves.

You'll have to excuse my ignorance here, but we may as well be speaking a foreign language, and I need a sure-fire guaranteed-to-work answer where I can install a script not have to guess the correct chmod.

Cloud Class® Course: Ruby Fundamentals

This course will introduce you to Ruby, as well as teach you about classes, methods, variables, data structures, loops, enumerable methods, and finishing touches.

PolemicAuthor Commented:
I've rejected jlms' answer because I need a definitive response.  I'm not equipped to choose between three or four options because I don't have sufficient understanding of the likely effects.  What I need is someone to tell me either "install them and chmod them xxx" or alternatively a list of "if... then..." answers which will allow me to easily choose which chmod setting to use on a particular script.  jlms, you're welcome to re-submit your answer in this form, but having not heard from you for a few days I felt it only fair to let others have a go at answering.
"How do I stop people who are not in my group from reading a directory?"
Type chmod o-r directory while you are in the directory above it.
"How do I stop people who are not in my group from writing to a directory?"
Type chmod g-w directory while you are in the directory above it.

How do I run my own CGI programs?
Put your CGI programs in the cgi-bin directory you will create in any directory. Make sure you upload them in ASCII mode.
Change permissions to 755 for the script (chmod 755 script-name)
PolemicAuthor Commented:
Sorry, but this isn't the comprehensive answer I'm looking for.  What is my "group"?? As I said I have no real knowledge of this topic at all, and need a kind of if... then... or something else to which I can refer.

I have the directory, and I have its permission set to 755.  What should I do with the scripts in it?  Do different cgi scripts need different permissions?  If so, how do I determine what permission to set and exactly what is that permission, in the format "chmod XXX" please?

And is it necessary, having set permission on the directory to 755, to restrict access to it via .htaccess, or will that prevent the scripts inside it from being executed?


What web server are you using (e.g. Apache, NCSA, etc.)?

Where are your htdocs run from (e.g. /var/www/domain/htdocs)?

Where are your cgi's run from (e.g. /var/www/domain/cgi-bin)?

Once I get an answer, I will post the exact syntax for you to type in order to protect your server, the cgi's, etc., etc.

PolemicAuthor Commented:

I'm told it's an Apache server.  That's all the info I was able to get from the manual - if you need more, tell me what commands to enter to get the server to list the version etc etc.

Now, paths:
ht docs: usr/local/etc/httpd/htdocs/polemic
cgi's: usr/local/etc/httpd/htdocs/polemic/cgi-bin
perl: /usr/bin/perl

I finally got some scripts running, but only by deleting the .htaccess file from the cgi-bin directory.  Keeping it there was giving me "500 Server Error" messages.

And I'm still getting conflicting advice from the various scripts readme's as to the right chmod - most seem to say 755, with the odd data.txt file and suchlike to 777, but others say different.

Hope that's what you wanted to know, turnkey.  If not, I'll do my best to track down other relevant info if you give me some idea how to get it.

Thanks, Polemic

PolemicAuthor Commented:
Thanks turnkey.  The only problem I'll have with this is that I doubt very much that they'll restart the server for me because other sites are on it as well and they're always telling me that I mustn't do anything to interrupt their service.  But that's not your fault - it's a comprehensive easily understandable answer that even I can understand!  Thanks.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.