response, then this response can be replaced with either some
friendlier text or by a redirection to another URL (local or
external).
-
+
<P>
-
+
<DT>Old behavior
<DD>NCSA httpd 1.3 would return some boring old error/problem message
response, then this response can be replaced with either some
friendlier text or by a redirection to another URL (local or
external).
-
+
<P>
-
+
<DT>Old behavior
<DD>NCSA httpd 1.3 would return some boring old error/problem message
connection stays in the FIN_WAIT_2 state until one of the following
happens:<P>
<UL>
- <LI>The client opens a new connection to the same or a different
- site, which causes it to fully close the older connection on
+ <LI>The client opens a new connection to the same or a different
+ site, which causes it to fully close the older connection on
that socket.
- <LI>The user exits the client, which on some (most?) clients
- causes the OS to fully shutdown the connection.
- <LI>The FIN_WAIT_2 times out, on servers that have a timeout
- for this state.
+ <LI>The user exits the client, which on some (most?) clients
+ causes the OS to fully shutdown the connection.
+ <LI>The FIN_WAIT_2 times out, on servers that have a timeout
+ for this state.
</UL><P>
If you are lucky, this means that the buggy client will fully close the
connection and release the resources on your server. However, there
The clients on which this problem has been verified to exist:<P>
<UL>
- <LI>Mozilla/3.01 (X11; I; FreeBSD 2.1.5-RELEASE i386)
- <LI>Mozilla/2.02 (X11; I; FreeBSD 2.1.5-RELEASE i386)
- <LI>Mozilla/3.01Gold (X11; I; SunOS 5.5 sun4m)
- <LI>MSIE 3.01 on the Macintosh
- <LI>MSIE 3.01 on Windows 95
+ <LI>Mozilla/3.01 (X11; I; FreeBSD 2.1.5-RELEASE i386)
+ <LI>Mozilla/2.02 (X11; I; FreeBSD 2.1.5-RELEASE i386)
+ <LI>Mozilla/3.01Gold (X11; I; SunOS 5.5 sun4m)
+ <LI>MSIE 3.01 on the Macintosh
+ <LI>MSIE 3.01 on Windows 95
</UL><P>
This does not appear to be a problem on:
<UL>
- <LI>Mozilla/3.01 (Win95; I)
+ <LI>Mozilla/3.01 (Win95; I)
</UL>
<P>
The following systems are known to have a timeout:
<P>
<UL>
- <LI><A HREF="http://www.freebsd.org/">FreeBSD</A> versions starting at 2.0 or possibly earlier.
- <LI><A HREF="http://www.netbsd.org/">NetBSD</A> version 1.2(?)
- <LI><A HREF="http://www.openbsd.org/">OpenBSD</A> all versions(?)
- <LI><A HREF="http://www.bsdi.com/">BSD/OS</A> 2.1, with the
- <A HREF="ftp://ftp.bsdi.com/bsdi/patches/patches-2.1/K210-027">
- K210-027</A> patch installed.
- <LI><A HREF="http://www.sun.com/">Solaris</A> as of around version
- 2.2. The timeout can be tuned by using <CODE>ndd</CODE> to
- modify <CODE>tcp_fin_wait_2_flush_interval</CODE>, but the
- default should be appropriate for most servers and improper
- tuning can have negative impacts.
- <LI><A HREF="http://www.sco.com/">SCO TCP/IP Release 1.2.1</A>
- can be modified to have a timeout by following
- <A HREF="http://www.sco.com/cgi-bin/waisgate?WAISdocID=2242622956+0+0+0&WAISaction=retrieve"> SCO's instructions</A>.
- <LI><A HREF="http://www.linux.org/">Linux</A> 2.0.x and
- earlier(?)
- <LI><A HREF="http://www.hp.com/">HP-UX</A> 10.x defaults to
- terminating connections in the FIN_WAIT_2 state after the
- normal keepalive timeouts. This does not
- refer to the persistent connection or HTTP keepalive
- timeouts, but the <CODE>SO_LINGER</CODE> socket option
- which is enabled by Apache. This parameter can be adjusted
- by using <CODE>nettune</CODE> to modify parameters such as
- <CODE>tcp_keepstart</CODE> and <CODE>tcp_keepstop</CODE>.
- In later revisions, there is an explicit timer for
- connections in FIN_WAIT_2 that can be modified; contact HP
- support for details.
- <LI><A HREF="http://www.sgi.com/">SGI IRIX</A> can be patched to
- support a timeout. For IRIX 5.3, 6.2, and 6.3,
- use patches 1654, 1703 and 1778 respectively. If you
- have trouble locating these patches, please contact your
- SGI support channel for help.
- <LI><A HREF="http://www.ncr.com/">NCR's MP RAS Unix</A> 2.xx and
- 3.xx both have FIN_WAIT_2 timeouts. In 2.xx it is non-tunable
- at 600 seconds, while in 3.xx it defaults to 600 seconds and
- is calculated based on the tunable "max keep alive probes"
- (default of 8) multiplied by the "keep alive interval" (default
- 75 seconds).
- <LI><A HREF="http://www.sequent.com">Squent's ptx/TCP/IP for
- DYNIX/ptx</A> has had a FIN_WAIT_2 timeout since around
- release 4.1 in mid-1994.
+
<LI><A HREF="http://www.freebsd.org/">FreeBSD</A> versions starting at 2.0 or possibly earlier.
+
<LI><A HREF="http://www.netbsd.org/">NetBSD</A> version 1.2(?)
+
<LI><A HREF="http://www.openbsd.org/">OpenBSD</A> all versions(?)
+
<LI><A HREF="http://www.bsdi.com/">BSD/OS</A> 2.1, with the
+
<A HREF="ftp://ftp.bsdi.com/bsdi/patches/patches-2.1/K210-027">
+ K210-027</A> patch installed.
+
<LI><A HREF="http://www.sun.com/">Solaris</A> as of around version
+ 2.2. The timeout can be tuned by using <CODE>ndd</CODE> to
+ modify <CODE>tcp_fin_wait_2_flush_interval</CODE>, but the
+ default should be appropriate for most servers and improper
+ tuning can have negative impacts.
+
<LI><A HREF="http://www.sco.com/">SCO TCP/IP Release 1.2.1</A>
+ can be modified to have a timeout by following
+
<A HREF="http://www.sco.com/cgi-bin/waisgate?WAISdocID=2242622956+0+0+0&WAISaction=retrieve"> SCO's instructions</A>.
+
<LI><A HREF="http://www.linux.org/">Linux</A> 2.0.x and
+ earlier(?)
+
<LI><A HREF="http://www.hp.com/">HP-UX</A> 10.x defaults to
+ terminating connections in the FIN_WAIT_2 state after the
+ normal keepalive timeouts. This does not
+ refer to the persistent connection or HTTP keepalive
+ timeouts, but the <CODE>SO_LINGER</CODE> socket option
+ which is enabled by Apache. This parameter can be adjusted
+ by using <CODE>nettune</CODE> to modify parameters such as
+ <CODE>tcp_keepstart</CODE> and <CODE>tcp_keepstop</CODE>.
+ In later revisions, there is an explicit timer for
+ connections in FIN_WAIT_2 that can be modified; contact HP
+ support for details.
+
<LI><A HREF="http://www.sgi.com/">SGI IRIX</A> can be patched to
+ support a timeout. For IRIX 5.3, 6.2, and 6.3,
+ use patches 1654, 1703 and 1778 respectively. If you
+ have trouble locating these patches, please contact your
+ SGI support channel for help.
+
<LI><A HREF="http://www.ncr.com/">NCR's MP RAS Unix</A> 2.xx and
+ 3.xx both have FIN_WAIT_2 timeouts. In 2.xx it is non-tunable
+ at 600 seconds, while in 3.xx it defaults to 600 seconds and
+ is calculated based on the tunable "max keep alive probes"
+ (default of 8) multiplied by the "keep alive interval" (default
+ 75 seconds).
+
<LI><A HREF="http://www.sequent.com">Squent's ptx/TCP/IP for
+ DYNIX/ptx</A> has had a FIN_WAIT_2 timeout since around
+ release 4.1 in mid-1994.
</UL>
<P>
The following systems are known to not have a timeout:
<P>
<UL>
- <LI><A HREF="http://www.sun.com/">SunOS 4.x</A> does not and
- almost certainly never will have one because it as at the
- very end of its development cycle for Sun. If you have kernel
- source should be easy to patch.
+
<LI><A HREF="http://www.sun.com/">SunOS 4.x</A> does not and
+ almost certainly never will have one because it as at the
+ very end of its development cycle for Sun. If you have kernel
+ source should be easy to patch.
</UL>
<P>
There is a
</P>
<DL>
<DT><A
- HREF="API.html"
+ HREF="API.html"
>API</A>
</DT>
<DD>Description of Apache's Application Programming Interface.
</DD>
<DT><A
- HREF="FAQ.html"
+ HREF="FAQ.html"
>FAQ</A>
</DT>
<DD>Frequently-Asked Questions concerning the Apache project and server
</DD>
<DT><A
- HREF="client_block_api.html"
+ HREF="client_block_api.html"
>Reading Client Input in Apache 1.2</A>
</DT>
<DD>Describes differences between Apache 1.1 and 1.2 in how modules
read information from the client
</DD>
<DT><A
- HREF="compat_notes.html"
+ HREF="compat_notes.html"
>Compatibility with NCSA</A>
</DT>
<DD>Notes about Apache's compatibility with the NCSA server
</DD>
<DT><A
- HREF="fin_wait_2.html"
+ HREF="fin_wait_2.html"
><SAMP>FIN_WAIT_2</SAMP></A>
</DT>
<DD>A description of the causes of Apache processes going into the
<SAMP>FIN_WAIT_2</SAMP> state, and what you can do about it
</DD>
<DT><A
- HREF="howto.html"
+ HREF="howto.html"
>"How-To"</A>
</DT>
<DD>Instructions about how to accomplish some commonly-desired server
functionality changes
</DD>
<DT><A
- HREF="known_bugs.html"
+ HREF="known_bugs.html"
>Known Bugs</A>
</DT>
<DD>Just what it says - a list of known bugs in each of the Apache releases
</DD>
<DT><A
- HREF="nopgp.html"
+ HREF="nopgp.html"
>No PGP</A>
</DT>
<DD>Why we took PEM and PGP support out of the base Apache distribution
</DD>
<DT><A
- HREF="perf-bsd44.html"
+ HREF="perf-bsd44.html"
>Performance Notes (BSD 4.4)</A>
</DT>
<DD>Some notes about ways to improve/optimize Apache performance on
BSD 4.4 systems
</DD>
<DT><A
- HREF="perf-dec.html"
+ HREF="perf-dec.html"
>Performance Notes (Digital UNIX)</A>
</DT>
<DD>Extracts of USENET postings describing how to optimize Apache
performance on Digital UNIX systems
</DD>
<DT><A
- HREF="perf.html"
+ HREF="perf.html"
>Performance Notes (General)</A>
</DT>
<DD>Some generic notes about how to improve Apache performance
</DD>
<DT><A
- HREF="security_tips.html"
+ HREF="security_tips.html"
>Security Tips</A>
</DT>
<DD>Some "do"s - and "don't"s - for keeping your
Apache web site secure
</DD>
<DT><A
- HREF="vif-info.html"
+ HREF="vif-info.html"
>Virtual Hosts (IP-based)</A>
</DT>
<DD>Excerpts and notes about configuring and using Apache IP-based virtual
hosts
</DD>
<DT><A
- HREF="windoz_keepalive.html"
+ HREF="windoz_keepalive.html"
>Windows Bug with Web Keepalive</A>
</DT>
<DD>A brief description of a known problem with Microsoft Windows and
<strong>Status:</strong> Extension<br>
<strong>Module:</strong> mod_auth_anon<p>
- A list of one or more 'magic' userIDs which are allowed access
- without password verification. The userIDs are space separated.
- It is possible to use the ' and " quotes to allow a space in
- a userID as well as the \ escape character.
- <p>
- Please note that the comparison is <b>case-IN-sensitive</b>.
- <br>
- I strongly suggest that the magic username '<code>anonymous</code>'
- is always one of the allowed userIDs.
- <p>
- Example:<br>
- <code>
- Anonymous: anonymous "Not Registered" 'I don\'t know'
- </code><p>
- This would allow the user to enter without password verification
- by using the userId's 'anonymous', 'AnonyMous','Not Registered' and
- 'I Don't Know'.
+ A list of one or more 'magic' userIDs which are allowed access
+ without password verification. The userIDs are space separated.
+ It is possible to use the ' and " quotes to allow a space in
+ a userID as well as the \ escape character.
+ Please note that the comparison is <b>case-IN-sensitive</b>.
+ <br>
+ I strongly suggest that the magic username '<code>anonymous</code>'
+ is always one of the allowed userIDs.
+ Example:<br>
+ <code>
+ Anonymous: anonymous "Not Registered" 'I don\'t know'
+ This would allow the user to enter without password verification
+ by using the userId's 'anonymous', 'AnonyMous','Not Registered' and
+ 'I Don't Know'.
<HR>
<A name="Authoritative"><h2>Anonymous_Authoritative</h2></A>
When set 'on', there is no
fall-through to other authorization methods. So if a
userID does not match the values specified in the
- <code>Anonymous</code> directive, access is denied.
- <p>
- Be sure you know what you are doing when you decide to switch
- it on. And remember that it is the linking order of the modules
- (in the Configuration / Make file) which details the order
- in which the Authorization modules are queried.
+ <code>Anonymous</code> directive, access is denied.
+ Be sure you know what you are doing when you decide to switch
+ it on. And remember that it is the linking order of the modules
+ (in the Configuration / Make file) which details the order
+ in which the Authorization modules are queried.
<hr>
<A name="LogEmail"><h2>Anonymous_LogEmail</h2></A>
<strong>Status:</strong> Extension<br>
<strong>Module:</strong> mod_auth_anon<p>
- When set 'on', the default, the 'password' entered (which hopefully
- contains a sensible email address) is logged in the httpd-log file.
+ When set 'on', the default, the 'password' entered (which hopefully
+ contains a sensible email address) is logged in the httpd-log file.
<hr>
<A name="MustGiveEmail"><h2>Anonymous_MustGiveEmail</h2></a>
<strong>Status:</strong> Extension<br>
<strong>Module:</strong> mod_auth_anon<p>
- Specifies whether the user must specify an email
- address as the password. This prohibits blank passwords.
+ Specifies whether the user must specify an email
+ address as the password. This prohibits blank passwords.
<HR>
<A name="NoUserID"><h2>Anonymous_NoUserID</h2></A>
<strong>Status:</strong> Extension<br>
<strong>Module:</strong> mod_auth_anon<p>
- When set 'on', users can leave
- the userID (and perhaps the password field) empty. This
- can be very convenient for MS-Explorer users who can
- just hit return or click directly on the OK button; which
- seems a natural reaction.
+ When set 'on', users can leave
+ the userID (and perhaps the password field) empty. This
+ can be very convenient for MS-Explorer users who can
+ just hit return or click directly on the OK button; which
+ seems a natural reaction.
<hr>
<strong>Status:</strong> Extension<br>
<strong>Module:</strong> mod_auth_anon<p>
- When set 'on' the 'password' entered is
- checked for at least one '@' and a '.' to encourage users to enter
- valid email addresses (see the above <code>Auth_LogEmail</code>).
+ When set 'on' the 'password' entered is
+ checked for at least one '@' and a '.' to encourage users to enter
+ valid email addresses (see the above <code>Auth_LogEmail</code>).
<hr><a name="Example"><h2>Example</h2></a>
<dl>
<dt><code>
Anonymous anonymous guest www test welcome<p>
-Anonymous_MustGiveEmail on<br>
+Anonymous_MustGiveEmail on<br>
Anonymous_VerifyEmail on<br>
-Anonymous_NoUserId off<br>
-Anonymous_LogEmail on<br>
+Anonymous_NoUserId off<br>
+Anonymous_LogEmail on<br>
<p>
AuthName Use 'anonymous' & Email address for guest entry<br>
AuthType basic<p>
</dd>
<dt>Version 0.5<br></dt>
<dd>Added 'VerifyEmail' and 'LogEmail' options. Multiple
- 'anonymous' tokens allowed. more docs. Added Authoritative
- functionality.
+ 'anonymous' tokens allowed. more docs. Added Authoritative
+ functionality.
</dd>
</dl>
Unix egrep command.
<DT>( <I>test_condition</I> )
- <DD>true if <I>test_condition</I> is true
+ <DD>true if <I>test_condition</I> is true
<DT>! <I>test_condition</I>
- <DD>true if <I>test_condition</I> is false
+ <DD>true if <I>test_condition</I> is false
<DT><I>test_condition1</I> && <I>test_condition2</I>
- <DD>true if both <I>test_condition1</I> and
- <I>test_condition2</I> are true
+ <DD>true if both <I>test_condition1</I> and
+ <I>test_condition2</I> are true
<DT><I>test_condition1</I> || <I>test_condition2</I>
- <DD>true if either <I>test_condition1</I> or
- <I>test_condition2</I> is true
+ <DD>true if either <I>test_condition1</I> or
+ <I>test_condition2</I> is true
</DL>
<P> "<I>=</I>" and "<I>!=</I>" bind more tightly than "<I>&&</I>" and
<li><a href="#shortname">Using Netscape hostname shortcuts</a>
<li><a href="#mimetypes">Why doesn't file type <i>xxx</i> download via FTP?</a>
<li><a href="#startup">Why does Apache start more slowly when using the
- proxy module?</a>
+ proxy module?</a>
<li><a href="#socks">Can I use the Apache proxy module with my SOCKS proxy?</a>
</ul>
</pre>
<h2><a name="startup">Why does Apache start more slowly when using the
- proxy module?</a></h2>
+ proxy module?</a></h2>
If you're using the <code>ProxyBlock</code> or <code>NoCache</code>
directives, hostnames' IP addresses are looked up and cached during
which will be expanded. You can use this flag more than once to set more
than one variable. The variables can be later dereferenced at a lot of
situations, but the usual location will be from within XSSI (via
- <tt><!--#echo var="VAR"--></tt>) or CGI (e.g. <tt>$ENV{'VAR'}</tt>).
- But additionally you can also dereference it in a following RewriteCond
- pattern via <tt>%{ENV:VAR}</tt>. Use this to strip but remember
- information from URLs.
+ <tt><!--#echo var="VAR"--></tt>) or CGI (e.g. <tt>$ENV{'VAR'}</tt>).
+ But additionally you can also dereference it in a following RewriteCond
+ pattern via <tt>%{ENV:VAR}</tt>. Use this to strip but remember
+ information from URLs.
</ul>
<p>
Do this by adding the following to the AUX_CFLAGS line in the
"Configuration" file and then recompiling as usual.
<pre>
- AUX_CFLAGS= (something) -DSTATUS
+ AUX_CFLAGS= (something) -DSTATUS
</pre>
<BLOCKQUOTE>
<UL>
<LI><A HREF="http://www.digital.com/info/internet/document/ias/tuning.html">DIGITAL
- UNIX Tuning Parameters for Web Servers</A>
+ UNIX Tuning Parameters for Web Servers</A>
<LI>We have some <A HREF="perf-dec.html">newsgroup postings</A> on how to tune
- Digital UNIX 3.2 and 4.0.
+ Digital UNIX 3.2 and 4.0.
</UL>
<P><HR>
The defaults for each variable are:
<PRE>
-MinSpareServers 5
-MaxSpareServers 10
-StartServers 5
+MinSpareServers 5
+MaxSpareServers 10
+StartServers 5
</PRE>
There is an absolute maximum number of simultaneous children defined
<P ALIGN="LEFT">
<OL>
- <LH><BIG><STRONG>CONTENTS</STRONG></BIG></LH>
- <LI><A HREF="#what">What is suEXEC?</A></LI>
- <LI><A HREF="#before">Before we begin.</A></LI>
- <LI><A HREF="#model">suEXEC Security Model.</A></LI>
- <LI><A HREF="#install">Configuring & Installing suEXEC</A></LI>
- <LI><A HREF="#enable">Enabling & Disabling suEXEC</A></LI>
- <LI><A HREF="#debug">Debugging suEXEC</A></LI>
- <LI><A HREF="#jabberwock">Beware the Jabberwock: Warnings & Examples</A></LI>
+ <LH><BIG><STRONG>CONTENTS</STRONG></BIG></LH>
+ <LI><A HREF="#what">What is suEXEC?</A></LI>
+ <LI><A HREF="#before">Before we begin.</A></LI>
+ <LI><A HREF="#model">suEXEC Security Model.</A></LI>
+ <LI><A HREF="#install">Configuring & Installing suEXEC</A></LI>
+ <LI><A HREF="#enable">Enabling & Disabling suEXEC</A></LI>
+ <LI><A HREF="#debug">Debugging suEXEC</A></LI>
+ <LI><A HREF="#jabberwock">Beware the Jabberwock: Warnings &
+ Examples</A></LI>
</OL>
</P>
The wrapper then employs the following process to determine success or
failure -- if any one of these conditions fail, the program logs the failure
and exits with an error, otherwise it will continue:
- <OL>
- <LI><STRONG>Was the wrapper called with the proper number of arguments?</STRONG>
- <BLOCKQUOTE>
- The wrapper will only execute if it is given the proper number of arguments.
- The proper argument format is known to the Apache web server. If the wrapper
- is not receiving the proper number of arguments, it is either being hacked, or
- there is something wrong with the suEXEC portion of your Apache binary.
- </BLOCKQUOTE>
- </LI>
- <LI><STRONG>Is the user executing this wrapper a valid user of this system?</STRONG>
- <BLOCKQUOTE>
- This is to ensure that the user executing the wrapper is truly a user of the system.
- </BLOCKQUOTE>
- </LI>
- <LI><STRONG>Is this valid user allowed to run the wrapper?</STRONG>
- <BLOCKQUOTE>
- Is this user the user allowed to run this wrapper? Only one user (the Apache
- user) is allowed to execute this program.
- </BLOCKQUOTE>
- </LI>
- <LI><STRONG>Does the target program have an unsafe hierarchical reference?</STRONG>
- <BLOCKQUOTE>
- Does the target program contain a leading '/' or have a '..' backreference? These
- are not allowed; the target program must reside within the Apache webspace.
- </BLOCKQUOTE>
- </LI>
- <LI><STRONG>Is the target user name valid?</STRONG>
- <BLOCKQUOTE>
- Does the target user exist?
- </BLOCKQUOTE>
- </LI>
- <LI><STRONG>Is the target group name valid?</STRONG>
- <BLOCKQUOTE>
- Does the target group exist?
- </BLOCKQUOTE>
- </LI>
- <LI><STRONG>Is the target user <EM>NOT</EM> superuser?</STRONG>
- <BLOCKQUOTE>
- Presently, suEXEC does not allow 'root' to execute CGI/SSI programs.
- </BLOCKQUOTE>
- </LI>
- <LI><STRONG>Is the target userid <EM>ABOVE</EM> the minimum ID number?</STRONG>
- <BLOCKQUOTE>
- The minimum user ID number is specified during configuration. This allows you
- to set the lowest possible userid that will be allowed to execute CGI/SSI programs.
- This is useful to block out "system" accounts.
- </BLOCKQUOTE>
- </LI>
- <LI><STRONG>Is the target group <EM>NOT</EM> the superuser group?</STRONG>
- <BLOCKQUOTE>
- Presently, suEXEC does not allow the 'root' group to execute CGI/SSI programs.
- </BLOCKQUOTE>
- </LI>
- <LI><STRONG>Is the target groupid <EM>ABOVE</EM> the minimum ID number?</STRONG>
- <BLOCKQUOTE>
- The minimum group ID number is specified during configuration. This allows you
- to set the lowest possible groupid that will be allowed to execute CGI/SSI programs.
- This is useful to block out "system" groups.
- </BLOCKQUOTE>
- </LI>
- <LI><STRONG>Can the wrapper successfully become the target user and group?</STRONG>
- <BLOCKQUOTE>
- Here is where the program becomes the target user and group via setuid and setgid
- calls. The group access list is also initialized with all of the groups of which
- the user is a member.
- </BLOCKQUOTE>
- </LI>
- <LI><STRONG>Does the directory in which the program resides exist?</STRONG>
- <BLOCKQUOTE>
- If it doesn't exist, it can't very well contain files.
- </BLOCKQUOTE>
- </LI>
- <LI><STRONG>Is the directory within the Apache webspace?</STRONG>
- <BLOCKQUOTE>
- If the request is for a regular portion of the server, is the requested directory
- within the server's document root? If the request is for a UserDir, is the requested
- directory within the user's document root?
- </BLOCKQUOTE>
- </LI>
- <LI><STRONG>Is the directory <EM>NOT</EM> writable by anyone else?</STRONG>
- <BLOCKQUOTE>
- We don't want to open up the directory to others; only the owner user may be able
- to alter this directories contents.
- </BLOCKQUOTE>
- </LI>
- <LI><STRONG>Does the target program exist?</STRONG>
- <BLOCKQUOTE>
- If it doesn't exists, it can't very well be executed.
- </BLOCKQUOTE>
- </LI>
- <LI><STRONG>Is the target program <EM>NOT</EM> writable by anyone else?</STRONG>
- <BLOCKQUOTE>
- We don't want to give anyone other than the owner the ability to change the program.
- </BLOCKQUOTE>
- </LI>
- <LI><STRONG>Is the target program <EM>NOT</EM> setuid or setgid?</STRONG>
- <BLOCKQUOTE>
- We do not want to execute programs that will then change our UID/GID again.
- </BLOCKQUOTE>
- </LI>
- <LI><STRONG>Is the target user/group the same as the program's user/group?</STRONG>
- <BLOCKQUOTE>
- Is the user the owner of the file?
- </BLOCKQUOTE>
- </LI>
- <LI><STRONG>Can we successfully clean the process environment to ensure safe operations?</STRONG>
- <BLOCKQUOTE>
- suEXEC cleans the process' environment by establishing a safe execution PATH (defined
- during configuration), as well as only passing through those variables whose names
- are listed in the safe environment list (also created during configuration).
- </BLOCKQUOTE>
- </LI>
- <LI><STRONG>Can we successfully become the target program and execute?</STRONG>
- <BLOCKQUOTE>
- Here is where suEXEC ends and the target program begins.
- </BLOCKQUOTE>
- </LI>
- </OL>
+ <LI><STRONG>Was the wrapper called with the proper number of arguments?</STRONG>
+ The wrapper will only execute if it is given the proper number of arguments.
+ The proper argument format is known to the Apache web server. If the wrapper
+ is not receiving the proper number of arguments, it is either being hacked, or
+ there is something wrong with the suEXEC portion of your Apache binary.
+ </BLOCKQUOTE>
+ </LI>
+ <LI><STRONG>Is the user executing this wrapper a valid user of this system?</STRONG>
+ This is to ensure that the user executing the wrapper is truly a user of the system.
+ </BLOCKQUOTE>
+ </LI>
+ <LI><STRONG>Is this valid user allowed to run the wrapper?</STRONG>
+ Is this user the user allowed to run this wrapper? Only one user (the Apache
+ user) is allowed to execute this program.
+ </BLOCKQUOTE>
+ </LI>
+ <LI><STRONG>Does the target program have an unsafe hierarchical reference?</STRONG>
+ Does the target program contain a leading '/' or have a '..' backreference? These
+ are not allowed; the target program must reside within the Apache webspace.
+ </BLOCKQUOTE>
+ </LI>
+ <LI><STRONG>Is the target user name valid?</STRONG>
+ Does the target user exist?
+ </BLOCKQUOTE>
+ </LI>
+ <LI><STRONG>Is the target group name valid?</STRONG>
+ Does the target group exist?
+ </BLOCKQUOTE>
+ </LI>
+ <LI><STRONG>Is the target user <EM>NOT</EM> superuser?</STRONG>
+ Presently, suEXEC does not allow 'root' to execute CGI/SSI programs.
+ </BLOCKQUOTE>
+ </LI>
+ <LI><STRONG>Is the target userid <EM>ABOVE</EM> the minimum ID number?</STRONG>
+ The minimum user ID number is specified during configuration. This allows you
+ to set the lowest possible userid that will be allowed to execute CGI/SSI programs.
+ This is useful to block out "system" accounts.
+ </BLOCKQUOTE>
+ </LI>
+ <LI><STRONG>Is the target group <EM>NOT</EM> the superuser group?</STRONG>
+ Presently, suEXEC does not allow the 'root' group to execute CGI/SSI programs.
+ </BLOCKQUOTE>
+ </LI>
+ <LI><STRONG>Is the target groupid <EM>ABOVE</EM> the minimum ID number?</STRONG>
+ The minimum group ID number is specified during configuration. This allows you
+ to set the lowest possible groupid that will be allowed to execute CGI/SSI programs.
+ This is useful to block out "system" groups.
+ </BLOCKQUOTE>
+ </LI>
+ <LI><STRONG>Can the wrapper successfully become the target user and group?</STRONG>
+ Here is where the program becomes the target user and group via setuid and setgid
+ calls. The group access list is also initialized with all of the groups of which
+ the user is a member.
+ </BLOCKQUOTE>
+ </LI>
+ <LI><STRONG>Does the directory in which the program resides exist?</STRONG>
+ If it doesn't exist, it can't very well contain files.
+ </BLOCKQUOTE>
+ </LI>
+ <LI><STRONG>Is the directory within the Apache webspace?</STRONG>
+ If the request is for a regular portion of the server, is the requested directory
+ within the server's document root? If the request is for a UserDir, is the requested
+ directory within the user's document root?
+ </BLOCKQUOTE>
+ </LI>
+ <LI><STRONG>Is the directory <EM>NOT</EM> writable by anyone else?</STRONG>
+ We don't want to open up the directory to others; only the owner user may be able
+ to alter this directories contents.
+ </BLOCKQUOTE>
+ </LI>
+ <LI><STRONG>Does the target program exist?</STRONG>
+ If it doesn't exists, it can't very well be executed.
+ </BLOCKQUOTE>
+ </LI>
+ <LI><STRONG>Is the target program <EM>NOT</EM> writable by anyone else?</STRONG>
+ We don't want to give anyone other than the owner the ability to change the program.
+ </BLOCKQUOTE>
+ </LI>
+ <LI><STRONG>Is the target program <EM>NOT</EM> setuid or setgid?</STRONG>
+ We do not want to execute programs that will then change our UID/GID again.
+ </BLOCKQUOTE>
+ </LI>
+ <LI><STRONG>Is the target user/group the same as the program's user/group?</STRONG>
+ Is the user the owner of the file?
+ </BLOCKQUOTE>
+ </LI>
+ <LI><STRONG>Can we successfully clean the process environment to ensure safe operations?</STRONG>
+ suEXEC cleans the process' environment by establishing a safe execution PATH (defined
+ during configuration), as well as only passing through those variables whose names
+ are listed in the safe environment list (also created during configuration).
+ </BLOCKQUOTE>
+ </LI>
+ <LI><STRONG>Can we successfully become the target program and execute?</STRONG>
+ Here is where suEXEC ends and the target program begins.
+ </BLOCKQUOTE>
+ </LI>
+ </OL>
</P>
<P ALIGN="LEFT">
<STRONG><A HREF="suexec.html">BACK TO CONTENTS</A></STRONG>
</P>
-<H3><A NAME="install">Configuring & Installing suEXEC</A></H3>
+<H3><A NAME="install">Configuring & Installing suEXEC</A></H3>
<P ALIGN="LEFT">
Here's where we begin the fun. The configuration and installation of suEXEC is
a four step process: edit the suEXEC header file, compile suEXEC, place the
<STRONG><A HREF="suexec.html">BACK TO CONTENTS</A></STRONG>
</P>
-<H3><A NAME="enable">Enabling & Disabling suEXEC</A></H3>
+<H3><A NAME="enable">Enabling & Disabling suEXEC</A></H3>
<P ALIGN="LEFT">
After properly installing the <STRONG>suexec</STRONG> wrapper
executable, you must kill and restart the Apache server. A simple
<STRONG><A HREF="suexec.html">BACK TO CONTENTS</A></STRONG>
</P>
-<H3><A NAME="jabberwock">Beware the Jabberwock: Warnings & Examples</A></H3>
+<H3><A NAME="jabberwock">Beware the Jabberwock: Warnings & Examples</A></H3>
<P ALIGN="LEFT">
<STRONG>NOTE!</STRONG> This section may not be complete. For the latest
revision of this section of the documentation, see the Apache Group's
limitations on server setup. Please review these before submitting any
"bugs" regarding suEXEC.
<UL>
- <LH><STRONG>suEXEC Points Of Interest</STRONG></LH>
- <LI>Hierarchy limitations
- <BLOCKQUOTE>
- For security and efficiency reasons, all suexec requests must
- remain within either a top-level document root for virtual
- host requests, or one top-level personal document root for
- userdir requests. For example, if you have four VirtualHosts
- configured, you would need to structure all of your VHosts'
- document roots off of one main Apache document hierarchy to
- take advantage of suEXEC for VirtualHosts. (Example forthcoming.)
- </BLOCKQUOTE>
- </LI>
- <LI>suEXEC's PATH environment variable
- <BLOCKQUOTE>
- This can be a dangerous thing to change. Make certain every
- path you include in this define is a <STRONG>trusted</STRONG>
- directory. You don't want to open people up to having someone
- from across the world running a trojan horse on them.
- </BLOCKQUOTE>
- </LI>
- <LI>Altering the suEXEC code
- <BLOCKQUOTE>
- Again, this can cause <STRONG>Big Trouble</STRONG> if you try
- this without knowing what you are doing. Stay away from it
- if at all possible.
- </BLOCKQUOTE>
- </LI>
+ <LH><STRONG>suEXEC Points Of Interest</STRONG></LH>
+ <LI>Hierarchy limitations
+ For security and efficiency reasons, all suexec requests must
+ remain within either a top-level document root for virtual
+ host requests, or one top-level personal document root for
+ userdir requests. For example, if you have four VirtualHosts
+ configured, you would need to structure all of your VHosts'
+ document roots off of one main Apache document hierarchy to
+ take advantage of suEXEC for VirtualHosts. (Example forthcoming.)
+ </BLOCKQUOTE>
+ </LI>
+ <LI>suEXEC's PATH environment variable
+ This can be a dangerous thing to change. Make certain every
+ path you include in this define is a <STRONG>trusted</STRONG>
+ directory. You don't want to open people up to having someone
+ from across the world running a trojan horse on them.
+ </BLOCKQUOTE>
+ </LI>
+ <LI>Altering the suEXEC code
+ Again, this can cause <STRONG>Big Trouble</STRONG> if you try
+ this without knowing what you are doing. Stay away from it
+ if at all possible.
+ </BLOCKQUOTE>
+ </LI>
</UL>
<P ALIGN="CENTER">
<P ALIGN="LEFT">
<OL>
- <LH><BIG><STRONG>CONTENTS</STRONG></BIG></LH>
- <LI><A HREF="#what">What is suEXEC?</A></LI>
- <LI><A HREF="#before">Before we begin.</A></LI>
- <LI><A HREF="#model">suEXEC Security Model.</A></LI>
- <LI><A HREF="#install">Configuring & Installing suEXEC</A></LI>
- <LI><A HREF="#enable">Enabling & Disabling suEXEC</A></LI>
- <LI><A HREF="#debug">Debugging suEXEC</A></LI>
- <LI><A HREF="#jabberwock">Beware the Jabberwock: Warnings & Examples</A></LI>
+ <LH><BIG><STRONG>CONTENTS</STRONG></BIG></LH>
+ <LI><A HREF="#what">What is suEXEC?</A></LI>
+ <LI><A HREF="#before">Before we begin.</A></LI>
+ <LI><A HREF="#model">suEXEC Security Model.</A></LI>
+ <LI><A HREF="#install">Configuring & Installing suEXEC</A></LI>
+ <LI><A HREF="#enable">Enabling & Disabling suEXEC</A></LI>
+ <LI><A HREF="#debug">Debugging suEXEC</A></LI>
+ <LI><A HREF="#jabberwock">Beware the Jabberwock: Warnings &
+ Examples</A></LI>
</OL>
</P>
The wrapper then employs the following process to determine success or
failure -- if any one of these conditions fail, the program logs the failure
and exits with an error, otherwise it will continue:
- <OL>
- <LI><STRONG>Was the wrapper called with the proper number of arguments?</STRONG>
- <BLOCKQUOTE>
- The wrapper will only execute if it is given the proper number of arguments.
- The proper argument format is known to the Apache web server. If the wrapper
- is not receiving the proper number of arguments, it is either being hacked, or
- there is something wrong with the suEXEC portion of your Apache binary.
- </BLOCKQUOTE>
- </LI>
- <LI><STRONG>Is the user executing this wrapper a valid user of this system?</STRONG>
- <BLOCKQUOTE>
- This is to ensure that the user executing the wrapper is truly a user of the system.
- </BLOCKQUOTE>
- </LI>
- <LI><STRONG>Is this valid user allowed to run the wrapper?</STRONG>
- <BLOCKQUOTE>
- Is this user the user allowed to run this wrapper? Only one user (the Apache
- user) is allowed to execute this program.
- </BLOCKQUOTE>
- </LI>
- <LI><STRONG>Does the target program have an unsafe hierarchical reference?</STRONG>
- <BLOCKQUOTE>
- Does the target program contain a leading '/' or have a '..' backreference? These
- are not allowed; the target program must reside within the Apache webspace.
- </BLOCKQUOTE>
- </LI>
- <LI><STRONG>Is the target user name valid?</STRONG>
- <BLOCKQUOTE>
- Does the target user exist?
- </BLOCKQUOTE>
- </LI>
- <LI><STRONG>Is the target group name valid?</STRONG>
- <BLOCKQUOTE>
- Does the target group exist?
- </BLOCKQUOTE>
- </LI>
- <LI><STRONG>Is the target user <EM>NOT</EM> superuser?</STRONG>
- <BLOCKQUOTE>
- Presently, suEXEC does not allow 'root' to execute CGI/SSI programs.
- </BLOCKQUOTE>
- </LI>
- <LI><STRONG>Is the target userid <EM>ABOVE</EM> the minimum ID number?</STRONG>
- <BLOCKQUOTE>
- The minimum user ID number is specified during configuration. This allows you
- to set the lowest possible userid that will be allowed to execute CGI/SSI programs.
- This is useful to block out "system" accounts.
- </BLOCKQUOTE>
- </LI>
- <LI><STRONG>Is the target group <EM>NOT</EM> the superuser group?</STRONG>
- <BLOCKQUOTE>
- Presently, suEXEC does not allow the 'root' group to execute CGI/SSI programs.
- </BLOCKQUOTE>
- </LI>
- <LI><STRONG>Is the target groupid <EM>ABOVE</EM> the minimum ID number?</STRONG>
- <BLOCKQUOTE>
- The minimum group ID number is specified during configuration. This allows you
- to set the lowest possible groupid that will be allowed to execute CGI/SSI programs.
- This is useful to block out "system" groups.
- </BLOCKQUOTE>
- </LI>
- <LI><STRONG>Can the wrapper successfully become the target user and group?</STRONG>
- <BLOCKQUOTE>
- Here is where the program becomes the target user and group via setuid and setgid
- calls. The group access list is also initialized with all of the groups of which
- the user is a member.
- </BLOCKQUOTE>
- </LI>
- <LI><STRONG>Does the directory in which the program resides exist?</STRONG>
- <BLOCKQUOTE>
- If it doesn't exist, it can't very well contain files.
- </BLOCKQUOTE>
- </LI>
- <LI><STRONG>Is the directory within the Apache webspace?</STRONG>
- <BLOCKQUOTE>
- If the request is for a regular portion of the server, is the requested directory
- within the server's document root? If the request is for a UserDir, is the requested
- directory within the user's document root?
- </BLOCKQUOTE>
- </LI>
- <LI><STRONG>Is the directory <EM>NOT</EM> writable by anyone else?</STRONG>
- <BLOCKQUOTE>
- We don't want to open up the directory to others; only the owner user may be able
- to alter this directories contents.
- </BLOCKQUOTE>
- </LI>
- <LI><STRONG>Does the target program exist?</STRONG>
- <BLOCKQUOTE>
- If it doesn't exists, it can't very well be executed.
- </BLOCKQUOTE>
- </LI>
- <LI><STRONG>Is the target program <EM>NOT</EM> writable by anyone else?</STRONG>
- <BLOCKQUOTE>
- We don't want to give anyone other than the owner the ability to change the program.
- </BLOCKQUOTE>
- </LI>
- <LI><STRONG>Is the target program <EM>NOT</EM> setuid or setgid?</STRONG>
- <BLOCKQUOTE>
- We do not want to execute programs that will then change our UID/GID again.
- </BLOCKQUOTE>
- </LI>
- <LI><STRONG>Is the target user/group the same as the program's user/group?</STRONG>
- <BLOCKQUOTE>
- Is the user the owner of the file?
- </BLOCKQUOTE>
- </LI>
- <LI><STRONG>Can we successfully clean the process environment to ensure safe operations?</STRONG>
- <BLOCKQUOTE>
- suEXEC cleans the process' environment by establishing a safe execution PATH (defined
- during configuration), as well as only passing through those variables whose names
- are listed in the safe environment list (also created during configuration).
- </BLOCKQUOTE>
- </LI>
- <LI><STRONG>Can we successfully become the target program and execute?</STRONG>
- <BLOCKQUOTE>
- Here is where suEXEC ends and the target program begins.
- </BLOCKQUOTE>
- </LI>
- </OL>
+ <LI><STRONG>Was the wrapper called with the proper number of arguments?</STRONG>
+ The wrapper will only execute if it is given the proper number of arguments.
+ The proper argument format is known to the Apache web server. If the wrapper
+ is not receiving the proper number of arguments, it is either being hacked, or
+ there is something wrong with the suEXEC portion of your Apache binary.
+ </BLOCKQUOTE>
+ </LI>
+ <LI><STRONG>Is the user executing this wrapper a valid user of this system?</STRONG>
+ This is to ensure that the user executing the wrapper is truly a user of the system.
+ </BLOCKQUOTE>
+ </LI>
+ <LI><STRONG>Is this valid user allowed to run the wrapper?</STRONG>
+ Is this user the user allowed to run this wrapper? Only one user (the Apache
+ user) is allowed to execute this program.
+ </BLOCKQUOTE>
+ </LI>
+ <LI><STRONG>Does the target program have an unsafe hierarchical reference?</STRONG>
+ Does the target program contain a leading '/' or have a '..' backreference? These
+ are not allowed; the target program must reside within the Apache webspace.
+ </BLOCKQUOTE>
+ </LI>
+ <LI><STRONG>Is the target user name valid?</STRONG>
+ Does the target user exist?
+ </BLOCKQUOTE>
+ </LI>
+ <LI><STRONG>Is the target group name valid?</STRONG>
+ Does the target group exist?
+ </BLOCKQUOTE>
+ </LI>
+ <LI><STRONG>Is the target user <EM>NOT</EM> superuser?</STRONG>
+ Presently, suEXEC does not allow 'root' to execute CGI/SSI programs.
+ </BLOCKQUOTE>
+ </LI>
+ <LI><STRONG>Is the target userid <EM>ABOVE</EM> the minimum ID number?</STRONG>
+ The minimum user ID number is specified during configuration. This allows you
+ to set the lowest possible userid that will be allowed to execute CGI/SSI programs.
+ This is useful to block out "system" accounts.
+ </BLOCKQUOTE>
+ </LI>
+ <LI><STRONG>Is the target group <EM>NOT</EM> the superuser group?</STRONG>
+ Presently, suEXEC does not allow the 'root' group to execute CGI/SSI programs.
+ </BLOCKQUOTE>
+ </LI>
+ <LI><STRONG>Is the target groupid <EM>ABOVE</EM> the minimum ID number?</STRONG>
+ The minimum group ID number is specified during configuration. This allows you
+ to set the lowest possible groupid that will be allowed to execute CGI/SSI programs.
+ This is useful to block out "system" groups.
+ </BLOCKQUOTE>
+ </LI>
+ <LI><STRONG>Can the wrapper successfully become the target user and group?</STRONG>
+ Here is where the program becomes the target user and group via setuid and setgid
+ calls. The group access list is also initialized with all of the groups of which
+ the user is a member.
+ </BLOCKQUOTE>
+ </LI>
+ <LI><STRONG>Does the directory in which the program resides exist?</STRONG>
+ If it doesn't exist, it can't very well contain files.
+ </BLOCKQUOTE>
+ </LI>
+ <LI><STRONG>Is the directory within the Apache webspace?</STRONG>
+ If the request is for a regular portion of the server, is the requested directory
+ within the server's document root? If the request is for a UserDir, is the requested
+ directory within the user's document root?
+ </BLOCKQUOTE>
+ </LI>
+ <LI><STRONG>Is the directory <EM>NOT</EM> writable by anyone else?</STRONG>
+ We don't want to open up the directory to others; only the owner user may be able
+ to alter this directories contents.
+ </BLOCKQUOTE>
+ </LI>
+ <LI><STRONG>Does the target program exist?</STRONG>
+ If it doesn't exists, it can't very well be executed.
+ </BLOCKQUOTE>
+ </LI>
+ <LI><STRONG>Is the target program <EM>NOT</EM> writable by anyone else?</STRONG>
+ We don't want to give anyone other than the owner the ability to change the program.
+ </BLOCKQUOTE>
+ </LI>
+ <LI><STRONG>Is the target program <EM>NOT</EM> setuid or setgid?</STRONG>
+ We do not want to execute programs that will then change our UID/GID again.
+ </BLOCKQUOTE>
+ </LI>
+ <LI><STRONG>Is the target user/group the same as the program's user/group?</STRONG>
+ Is the user the owner of the file?
+ </BLOCKQUOTE>
+ </LI>
+ <LI><STRONG>Can we successfully clean the process environment to ensure safe operations?</STRONG>
+ suEXEC cleans the process' environment by establishing a safe execution PATH (defined
+ during configuration), as well as only passing through those variables whose names
+ are listed in the safe environment list (also created during configuration).
+ </BLOCKQUOTE>
+ </LI>
+ <LI><STRONG>Can we successfully become the target program and execute?</STRONG>
+ Here is where suEXEC ends and the target program begins.
+ </BLOCKQUOTE>
+ </LI>
+ </OL>
</P>
<P ALIGN="LEFT">
<STRONG><A HREF="suexec.html">BACK TO CONTENTS</A></STRONG>
</P>
-<H3><A NAME="install">Configuring & Installing suEXEC</A></H3>
+<H3><A NAME="install">Configuring & Installing suEXEC</A></H3>
<P ALIGN="LEFT">
Here's where we begin the fun. The configuration and installation of suEXEC is
a four step process: edit the suEXEC header file, compile suEXEC, place the
<STRONG><A HREF="suexec.html">BACK TO CONTENTS</A></STRONG>
</P>
-<H3><A NAME="enable">Enabling & Disabling suEXEC</A></H3>
+<H3><A NAME="enable">Enabling & Disabling suEXEC</A></H3>
<P ALIGN="LEFT">
After properly installing the <STRONG>suexec</STRONG> wrapper
executable, you must kill and restart the Apache server. A simple
<STRONG><A HREF="suexec.html">BACK TO CONTENTS</A></STRONG>
</P>
-<H3><A NAME="jabberwock">Beware the Jabberwock: Warnings & Examples</A></H3>
+<H3><A NAME="jabberwock">Beware the Jabberwock: Warnings & Examples</A></H3>
<P ALIGN="LEFT">
<STRONG>NOTE!</STRONG> This section may not be complete. For the latest
revision of this section of the documentation, see the Apache Group's
limitations on server setup. Please review these before submitting any
"bugs" regarding suEXEC.
<UL>
- <LH><STRONG>suEXEC Points Of Interest</STRONG></LH>
- <LI>Hierarchy limitations
- <BLOCKQUOTE>
- For security and efficiency reasons, all suexec requests must
- remain within either a top-level document root for virtual
- host requests, or one top-level personal document root for
- userdir requests. For example, if you have four VirtualHosts
- configured, you would need to structure all of your VHosts'
- document roots off of one main Apache document hierarchy to
- take advantage of suEXEC for VirtualHosts. (Example forthcoming.)
- </BLOCKQUOTE>
- </LI>
- <LI>suEXEC's PATH environment variable
- <BLOCKQUOTE>
- This can be a dangerous thing to change. Make certain every
- path you include in this define is a <STRONG>trusted</STRONG>
- directory. You don't want to open people up to having someone
- from across the world running a trojan horse on them.
- </BLOCKQUOTE>
- </LI>
- <LI>Altering the suEXEC code
- <BLOCKQUOTE>
- Again, this can cause <STRONG>Big Trouble</STRONG> if you try
- this without knowing what you are doing. Stay away from it
- if at all possible.
- </BLOCKQUOTE>
- </LI>
+ <LH><STRONG>suEXEC Points Of Interest</STRONG></LH>
+ <LI>Hierarchy limitations
+ For security and efficiency reasons, all suexec requests must
+ remain within either a top-level document root for virtual
+ host requests, or one top-level personal document root for
+ userdir requests. For example, if you have four VirtualHosts
+ configured, you would need to structure all of your VHosts'
+ document roots off of one main Apache document hierarchy to
+ take advantage of suEXEC for VirtualHosts. (Example forthcoming.)
+ </BLOCKQUOTE>
+ </LI>
+ <LI>suEXEC's PATH environment variable
+ This can be a dangerous thing to change. Make certain every
+ path you include in this define is a <STRONG>trusted</STRONG>
+ directory. You don't want to open people up to having someone
+ from across the world running a trojan horse on them.
+ </BLOCKQUOTE>
+ </LI>
+ <LI>Altering the suEXEC code
+ Again, this can cause <STRONG>Big Trouble</STRONG> if you try
+ this without knowing what you are doing. Stay away from it
+ if at all possible.
+ </BLOCKQUOTE>
+ </LI>
</UL>
<P ALIGN="CENTER">
projects / thirdparty / apache / httpd.git / commitdiff
