You are viewing a plain text version of this content. The canonical link for it is here.
Posted to docs@httpd.apache.org by Joshua Slive <jo...@slive.ca> on 2001/05/05 21:51:00 UTC
mod_cgid docs
Attached is just a quick scratch at some docs for mod_cgid.
(Also available at
http://garibaldi.commerce.ubc.ca:8080/ap20/manual/mod/mod_cgid.html )
If anyone can answer these questions, I would appreciate it
(yah, I could answer some of them myself if I dug far enough into the
source code):
- Under what circumstances is mod_cgid used and when is mod_cgi
used?
- Are there any security concerns related to the value of ScriptSock?
(ie. Should we warn against placing it in a non-root writable directory?)
- Are there any other differences between mod_cgi and mod_cgid that should
be documented?
Any other comments/suggestions also appreciated.
Joshua.
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<HTML>
<HEAD>
<TITLE>Apache module mod_cgi</TITLE>
</HEAD>
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
<BODY
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#000080"
ALINK="#FF0000"
>
<!--#include virtual="header.html" -->
<H1 ALIGN="CENTER">Module mod_cgid</H1>
<p>This module provides for execution of CGI scripts using an external
CGI daemon.</p>
<P><A
HREF="module-dict.html#Status"
REL="Help"
><STRONG>Status:</STRONG></A> Base
<BR>
<A
HREF="module-dict.html#SourceFile"
REL="Help"
><STRONG>Source File:</STRONG></A> mod_cgid.c
<BR>
<A
HREF="module-dict.html#ModuleIdentifier"
REL="Help"
><STRONG>Module Identifier:</STRONG></A> cgid_module
</P>
<H2>Summary</H2>
<p>On certain unix operating systems, forking a process from a
multi-threaded server is a very expensive operation because the new
process will replicate all the threads of the parent process. In
order to avoid incurring this expense on each CGI invocation, mod_cgid
creates an external daemon that is responsible for forking child
process to run CGI scripts. The main server communicates with this
daemon using a unix domain socket.</p>
<p>At the user level, this module is identical in configuration and
operation to <a href="mod_cgi.html">mod_cgi</a>. The only exception
is the new directive <code>Scriptsock</code> which gives the name of the
socket to use for communication with the cgi daemon.</p>
<h2>Directives</h2>
<ul>
<li><a href="mod_cgi.html#scriptlog">ScriptLog</a></li>
<li><a href="mod_cgi.html#scriptloglength">ScriptLogLength</a></li>
<li><a href="mod_cgi.html#scriptlogbuffer">ScriptLogBuffer</a></li>
<li><a href="#scriptsock">Scriptsock</a></li>
</ul>
<hr>
<H3><A NAME="scriptsock">Scriptsock</A> directive</H3>
<p><A
HREF="directive-dict.html#Syntax"
REL="Help"
><STRONG>Syntax:</STRONG></A> Scriptsock <EM>filename</EM><BR>
<A
HREF="directive-dict.html#Default"
REL="Help"
><STRONG>Default:</STRONG></A> logs/cgisock<BR>
<A
HREF="directive-dict.html#Context"
REL="Help"
><STRONG>Context:</STRONG></A> server config<BR>
<A
HREF="directive-dict.html#Status"
REL="Help"
><STRONG>Status:</STRONG></A> Base<br>
<A
HREF="directive-dict.html#Module"
REL="Help"
><STRONG>Module:</STRONG></A> mod_cgid</p>
<p>Sets the name of the socket to use for communication with the
CGI daemon.</p>
<!--#include virtual="footer.html" -->
</BODY>
</HTML>
---------------------------------------------------------------------
To unsubscribe, e-mail: apache-docs-unsubscribe@apache.org
For additional commands, e-mail: apache-docs-help@apache.org
Re: mod_cgid docs
Posted by rb...@covalent.net.
On Sat, 5 May 2001, Joshua Slive wrote:
> On Sat, 5 May 2001 rbb@covalent.net wrote:
> > > - Under what circumstances is mod_cgid used and when is mod_cgi
> > > used?
> >
> > Mod_cgid should be used whenever you are using a threaded MPM on Unix.
> > The reason for the module, is that Unix platforms historically are really
> > bad at forking threaded processes. They tend to create all the threads,
> > then kill off all but one in the new process. The IPC is less expensive
> > than this horribly inefficient forking.
>
> Sorry, my questions wasn't worded correctly. What I wanted to know is, in
> the current build system, is mod_cgid automatically chosen over mod_cgi if
> and only if a threaded mpm is used or is there some other algorithm?
Yes, we automatically use mod_cgid if a threaded MPM is chosen.
> > > - Are there any security concerns related to the value of ScriptSock?
> > > (ie. Should we warn against placing it in a non-root writable
> > > directory?)
> >
> > The ScriptSock should be placed in a non-root writable directory. That
> > socket is used to communicate with the CGI daemon process, so there are
> > definately security concerns around using it.
> >
>
> I'm guessing you mean to say that Scriptsock should NOT be placed in
> a directory where non-root users can write.
Yeah.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: apache-docs-unsubscribe@apache.org
For additional commands, e-mail: apache-docs-help@apache.org
Re: mod_cgid docs
Posted by Joshua Slive <jo...@slive.ca>.
On Sat, 5 May 2001 rbb@covalent.net wrote:
> > - Under what circumstances is mod_cgid used and when is mod_cgi
> > used?
>
> Mod_cgid should be used whenever you are using a threaded MPM on Unix.
> The reason for the module, is that Unix platforms historically are really
> bad at forking threaded processes. They tend to create all the threads,
> then kill off all but one in the new process. The IPC is less expensive
> than this horribly inefficient forking.
Sorry, my questions wasn't worded correctly. What I wanted to know is, in
the current build system, is mod_cgid automatically chosen over mod_cgi if
and only if a threaded mpm is used or is there some other algorithm?
>
> > - Are there any security concerns related to the value of ScriptSock?
> > (ie. Should we warn against placing it in a non-root writable
> > directory?)
>
> The ScriptSock should be placed in a non-root writable directory. That
> socket is used to communicate with the CGI daemon process, so there are
> definately security concerns around using it.
>
I'm guessing you mean to say that Scriptsock should NOT be placed in
a directory where non-root users can write.
Thanks for the info.
Joshua.
---------------------------------------------------------------------
To unsubscribe, e-mail: apache-docs-unsubscribe@apache.org
For additional commands, e-mail: apache-docs-help@apache.org
Re: mod_cgid docs
Posted by rb...@covalent.net.
On Sat, 5 May 2001, Joshua Slive wrote:
> Attached is just a quick scratch at some docs for mod_cgid.
> (Also available at
> http://garibaldi.commerce.ubc.ca:8080/ap20/manual/mod/mod_cgid.html )
I haven't had a chance to review the docs, but here are the answers to
your questions.
> - Under what circumstances is mod_cgid used and when is mod_cgi
> used?
Mod_cgid should be used whenever you are using a threaded MPM on Unix.
The reason for the module, is that Unix platforms historically are really
bad at forking threaded processes. They tend to create all the threads,
then kill off all but one in the new process. The IPC is less expensive
than this horribly inefficient forking.
> - Are there any security concerns related to the value of ScriptSock?
> (ie. Should we warn against placing it in a non-root writable
> directory?)
The ScriptSock should be placed in a non-root writable directory. That
socket is used to communicate with the CGI daemon process, so there are
definately security concerns around using it.
> - Are there any other differences between mod_cgi and mod_cgid that should
> be documented?
Nope.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: apache-docs-unsubscribe@apache.org
For additional commands, e-mail: apache-docs-help@apache.org