Re: cgi-bin

[Ken Hagan <ken@alacrity-it.com>]

Nobody has explained this yet so I will give it a whirl.  I was actually one of
the original designers of suExec back when it was called mod_suCGI and other
things like that. That was many, many dog years ago and it's long since evolved
beyond my kung-fu at the time.

Apache runs as one particular user (nobody, httpd, etc).  If you were to give
cgi-bins to all of your users, their programs would all execute as the same
account as which the server is running.  This would mean that their programs
could not write to files in their directories and that their programs would
have the exact same access rights as all other cgis on the system.  That would
cause a lot of problems.

Suexec was written to cause the cgi scripts to change their userid to the user
in whose directory the script was set.  There have to be a LOT of security
checks for this for a number of reasons:
    If not, other people could put cgis in your directory and run stuff as you
    If not, it's a setuid root program that might be exploited
    If not, the generally paranoid Apache group would not have let it in

Among the checks are that apache has to be compiled with information in it about
what the names of user directories are going to be (such as the terrible
public_html directory name which can be changed to www or htdocs or even
ramamalamadingdong).  You also need to make sure that the cgi directory being
used is owned by the right person and is not writeable by anyone else.  The
scripts themselves must also be the same.

suexec answered a need people had ten years ago.  If you really need it, it's
still there.  I would recommend using PHP or other much more efficient means of
letting multiple users have scripts in their directories unless you really have
to.  

If you have to, suexec is your man but you have to make sure you read the
documentation well when compiling it and make sure you turn on suexec logging
so you can figure out why a script is just plain not working.  A lot of times,
it's suexec doing its job and making sure the script is set up securely.

Sorry such a long response.  I'm always too verbose.

Quoting Harold Crouch <hcrouch@mchsi.com>:

> HC>> Where on systems that store multiple users' web pages do sysops
> HC>> normally store cgi scripts? In fact, where do the sysops store
> HC>> the web pages?
> 
> SP> That's entirely up to user preference and what access method you
> SP> make available to your customers.
> 
> 
> Sigh...  This is going to be one of those nights...   ;-)
> 
> Ok, guys, this is my first struggle with Apache.  I found the
> following in the Apache documentation.  
> ______________________________________________________________________
> Question:
> How do I allow each of my user directories to have a cgi-bin
> directory?
> 
> Answer:
> Remember that CGI execution does not need to be restricted only to
> cgi-bin directories. You can allow CGI script execution in arbitrary
> parts of your filesystem. There are many ways to give each user
> directory a cgi-bin directory such that anything requested as
> http://example.com/~user/cgi-bin/program will be executed as a CGI
> script. Two alternatives are:
> 
> 1. Place the cgi-bin directory next to the public_html directory:
> 	ScriptAliasMatch ^/~([^/]*)/cgi-bin/(.*) /home/$1/cgi-bin/$2
> 
> 2. Place the cgi-bin directory underneath the public_html directory:
> 	<Directory /home/*/public_html/cgi-bin>
> 	Options ExecCGI
> 	SetHandler cgi-script
> 	</Directory>
> 
> If you are using suexec, the first technique will not work because CGI
> scripts must be stored under the public_html directory.
> ______________________________________________________________________
> 
> I grok the question and the first paragraph of the answer.  The two
> alternatives and the comment about suexec go WAY over my head.  And
> there are no directories on my computer named "public_html.  Can some
> one please translate into english?
> 
> -
> To unsubscribe, send email to majordomo@silug.org with
> "unsubscribe silug-discuss" in the body.
> 



Ken Hagan
Technology Consultant
Alacrity-IT, Inc
http://www.alacrity-it.com/
618.499.0108

----------------------------------------------------------------
This message was sent using Alacrity-IT Webmail
	http://www.alacrity-it.com/

-
To unsubscribe, send email to majordomo@silug.org with
"unsubscribe silug-discuss" in the body.