Search the FAQ Archives

3 - A - B - C - D - E - F - G - H - I - J - K - L - M
N - O - P - Q - R - S - T - U - V - W - X - Y - Z
faqs.org - Internet FAQ Archives

FAQ: Frequently Asked Questions about CGI Programming
Section - 1.16 What do I need to know about file permissions and "chmod"?

( Single Page )
[ Usenet FAQs | Web FAQs | Documents | RFC Index | Cities ]


Top Document: FAQ: Frequently Asked Questions about CGI Programming
Previous Document: 1.15 What is the "CGI Overhead", and should I be worried about it?
Next Document: 1.17 What is CGIWrap, and how does it affect my program?
See reader questions & answers on this topic! - Help others by sharing your knowledge

Unix systems are designed for multiple users, and include provision
for protecting your work from unauthorised access by other users
of the system.  The file permissions determine who is permitted
to do what with your programs, data, and directories.  The command
that sets file permissions is chmod.

Web servers typically run as user "nobody".  That means that, setting
aside serious bugs (such as those in certain versions of the Frontpage
extensions), your files are absolutely secure from damage through the
webserver.  It also means that you may have to make explicit changes to
enable the server to access them in a CGI context.

There are two ways to run CGI:
- by default they run as the webserver user (nobody)
	For most purposes this is safest, as your programs and data
	are protected by the operating system from unauthorised access
	through possible bugs in your CGI.  However, when the CGI has
	to write to a file, that file must be writable to every web
	user on the system, and is therefore completely unprotected.
- setuid, they run under your own userid.
	This means that files written by your CGI can be secure.
	On the other hand, any bugs in your CGI could now compromise
	*all* your programs and data on the server.
	As an elementary security precaution, scripts (e.g. Perl) are
	prevented from running setuid by most OSs.  The "cgiwrap"
	program offers a workaround for this.

A third way you should *never* permit CGI to be run is:
- as root or setuid root, they can run as any user.
	This is extremely dangerous, as any bugs could compromise the
	entire server, including every user's files.  Fortunately only
	the system administrator can install setuid root programs.  If
	you are *at all* concerned about security, make sure that no such
	programs (in particular Frontpage extensions) are installed,
	regardless of whether you use them yourself.

For a proper overview, "man chmod".  Some modes that may be useful
in a typical CGI context are:

* CGI programs, 0755
* data files to be readable by CGI, 0644
* directories for data used by CGI, 0755
* data files to be writable by CGI, 0666 (data has absolutely no security)
* directories for data used by CGI with write access, 0777 (no security)
* CGI programs to run setuid, 4755
* data files for setuid CGI programs, 0600 or 0644
* directories for data used by setuid CGI programs, 0700 or 0755
* For a typical backend server process, 4750

Finally, if this answer tells you anything you didn't already know,
don't even think about trying to set up a secure server!


User Contributions:

Comment about this article, ask questions, or add new information about this topic:




Top Document: FAQ: Frequently Asked Questions about CGI Programming
Previous Document: 1.15 What is the "CGI Overhead", and should I be worried about it?
Next Document: 1.17 What is CGIWrap, and how does it affect my program?

Single Page

[ Usenet FAQs | Web FAQs | Documents | RFC Index ]

Send corrections/additions to the FAQ Maintainer:
Nick Kew <nick@webthing.com>





Last Update March 27 2014 @ 02:12 PM