You are viewing a plain text version of this content. The canonical link for it is here.
Posted to docs@httpd.apache.org by Colm MacCarthaigh <co...@stdlib.net> on 2003/09/28 16:33:54 UTC
[PATCH] [resend] [colm@stdlib.net IPv6 changes in bind.xml]
While I'm at it;
Rather than bother the list with resends, is it (or would it be more)
appropriate to open a wishlist/feature req bug for documentation
changes ?
----- Forwarded message from Colm MacCarthaigh <co...@stdlib.net> -----
From: Colm MacCarthaigh <co...@stdlib.net>
Reply-To: colm@stdlib.net
Date: Mon, 1 Sep 2003 15:54:48 +0100
To: docs@httpd.apache.org
Subject: IPv6 changes in bind.xml
Summary;
With Justins rewrite, and Jeffs and my patches now committed to the
server listen code there is no longer any need for different Listen
directives to use mapped/non-mapped addresses. Also cleared up that not all
platforms support v6-only sockets.
Index: bind.html.en
===================================================================
RCS file: /home/cvspublic/httpd-2.0/docs/manual/bind.html.en,v
retrieving revision 1.36
diff -u -u -r1.36 bind.html.en
--- bind.html.en 30 Jun 2003 01:16:29 -0000 1.36
+++ bind.html.en 1 Sep 2003 14:49:51 -0000
@@ -98,18 +98,14 @@
platforms. But even on systems where it is disallowed by default, a
special configure parameter can change this behavior for Apache.</p>
- <p>If you want Apache to handle IPv4 and IPv6 connections with a
- minimum of sockets, which requires using IPv4-mapped IPv6 addresses,
- specify the <code>--enable-v4-mapped</code> configure option and use
- generic Listen directives like the following:</p>
+ <p>On the other hand, on some platforms such as Linux and Tru64 the
+ <strong>only</strong> way to handle both IPv6 and IPv4 is to use
+ mapped addresses. If you want Apache to handle IPv4 and IPv6 connections
+ with a minimum of sockets, which requires using IPv4-mapped IPv6
+ addresses, specify the <code>--enable-v4-mapped</code> configure
+ option.</p>
- <div class="example"><p><code>
- Listen 80
- </code></p></div>
-
- <p>With <code>--enable-v4-mapped</code>, the Listen directives in the
- default configuration file created by Apache will use this form.
- <code>--enable-v4-mapped</code> is the default on all platforms but
+ <p><code>--enable-v4-mapped</code> is the default on all platforms but
FreeBSD, NetBSD, and OpenBSD, so this is probably how your Apache was
built.</p>
@@ -122,21 +118,11 @@
Listen 192.170.2.1:80
</code></p></div>
- <p>If you want Apache to handle IPv4 and IPv6 connections on separate
- sockets (i.e., to disable IPv4-mapped addresses), specify the
- <code>--disable-v4-mapped</code> configure option and use specific Listen
- directives like the following:</p>
-
- <div class="example"><p><code>
- Listen [::]:80<br />
- Listen 0.0.0.0:80
- </code></p></div>
-
- <p>With <code>--disable-v4-mapped</code>, the Listen directives in the
- default configuration file created by Apache will use this form.
- <code>--disable-v4-mapped</code> is the default on FreeBSD, NetBSD, and
- OpenBSD.</p>
-
+ <p>If your platform supports it and you want Apache to handle IPv4 and
+ IPv6 connections on separate sockets (i.e., to disable IPv4-mapped
+ addresses), specify the <code>--disable-v4-mapped</code> configure
+ option. <code>--disable-v4-mapped</code> is the default on FreeBSD,
+ NetBSD, and OpenBSD.</p>
</div><div class="top"><a href="#page-header"><img alt="top" src="./images/up.gif" /></a></div>
<div class="section">
<h2><a name="virtualhost" id="virtualhost">How This Works With Virtual Hosts</a></h2>
Index: bind.xml
===================================================================
RCS file: /home/cvspublic/httpd-2.0/docs/manual/bind.xml,v
retrieving revision 1.8
diff -u -u -r1.8 bind.xml
--- bind.xml 22 Jun 2003 15:31:23 -0000 1.8
+++ bind.xml 1 Sep 2003 14:49:51 -0000
@@ -89,18 +89,14 @@
platforms. But even on systems where it is disallowed by default, a
special configure parameter can change this behavior for Apache.</p>
- <p>If you want Apache to handle IPv4 and IPv6 connections with a
- minimum of sockets, which requires using IPv4-mapped IPv6 addresses,
- specify the <code>--enable-v4-mapped</code> configure option and use
- generic Listen directives like the following:</p>
+ <p>On the other hand, on some platforms such as Linux and Tru64 the
+ <strong>only</strong> way to handle both IPv6 and IPv4 is to use
+ mapped addresses. If you want Apache to handle IPv4 and IPv6 connections
+ with a minimum of sockets, which requires using IPv4-mapped IPv6
+ addresses, specify the <code>--enable-v4-mapped</code> configure
+ option.</p>
- <example>
- Listen 80
- </example>
-
- <p>With <code>--enable-v4-mapped</code>, the Listen directives in the
- default configuration file created by Apache will use this form.
- <code>--enable-v4-mapped</code> is the default on all platforms but
+ <p><code>--enable-v4-mapped</code> is the default on all platforms but
FreeBSD, NetBSD, and OpenBSD, so this is probably how your Apache was
built.</p>
@@ -113,21 +109,11 @@
Listen 192.170.2.1:80
</example>
- <p>If you want Apache to handle IPv4 and IPv6 connections on separate
- sockets (i.e., to disable IPv4-mapped addresses), specify the
- <code>--disable-v4-mapped</code> configure option and use specific Listen
- directives like the following:</p>
-
- <example>
- Listen [::]:80<br />
- Listen 0.0.0.0:80
- </example>
-
- <p>With <code>--disable-v4-mapped</code>, the Listen directives in the
- default configuration file created by Apache will use this form.
- <code>--disable-v4-mapped</code> is the default on FreeBSD, NetBSD, and
- OpenBSD.</p>
-
+ <p>If your platform supports it and you want Apache to handle IPv4 and
+ IPv6 connections on separate sockets (i.e., to disable IPv4-mapped
+ addresses), specify the <code>--disable-v4-mapped</code> configure
+ option. <code>--disable-v4-mapped</code> is the default on FreeBSD,
+ NetBSD, and OpenBSD.</p>
</section>
<section id="virtualhost">
--
Colm MacCárthaigh Public Key: colm+pgp@stdlib.net
colm@stdlib.net http://www.stdlib.net/
----- End forwarded message -----
--
Colm MacCárthaigh Public Key: colm+pgp@stdlib.net
colm@stdlib.net http://www.stdlib.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org
Re: [PATCH] [resend] [colm@stdlib.net IPv6 changes in bind.xml]
Posted by Erik Abele <er...@codefaktor.de>.
I finally got around to review and commit this patch ;-P
Thanks for the patience, Colm.
Btw, I also fixed some typos in your original patch, at least
I think I did so:
- "Allthough..." -> "Although..."
- "possiblity" -> "possibility"
- "apache" -> "Apache"
- "suexec" -> "suEXEC" (where applicable)
- "...to run as;" -> "to run as:"
- "webserver" -> "web-server" (to be consistent with the rest of the
doc)
plus some cosmetic fixes / clean-ups in the whole xml source to keep
the docs consistent (mostly <code>...</code>, formatting etc.) ;)
Cheers,
Erik
On 28/09/2003, at 09:10, Colm MacCarthaigh wrote:
> On Sun, Sep 28, 2003 at 03:03:30PM -0400, Cliff Woolley wrote:
>> On Sun, 28 Sep 2003, Colm MacCarthaigh wrote:
>>
>>>> The resends are not a bother. :) Should this change go in both
>>>> 2.0 and
>>>> 2.1 or just 2.1? I don't happen to remember whether the change it
>>>> goes
>>>> with was backported or not.
>>>
>>> sorry, just 2.1 :)
>>
>> Okay, that's what I did. So AFAIK all the patches you've
>> (re)submitted
>> are now committed to the right branches... thanks!
>
> That they are :) *does cvs diff* , this one is much less important
> (in fact the only thing actually wrong in the doc is the paths),
> but I'll resubmit it anyway:
<snipped the patch />
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org
Re: [PATCH] [resend] [colm@stdlib.net IPv6 changes in bind.xml]
Posted by Colm MacCarthaigh <co...@stdlib.net>.
On Sun, Sep 28, 2003 at 03:03:30PM -0400, Cliff Woolley wrote:
> On Sun, 28 Sep 2003, Colm MacCarthaigh wrote:
>
> > > The resends are not a bother. :) Should this change go in both 2.0 and
> > > 2.1 or just 2.1? I don't happen to remember whether the change it goes
> > > with was backported or not.
> >
> > sorry, just 2.1 :)
>
> Okay, that's what I did. So AFAIK all the patches you've (re)submitted
> are now committed to the right branches... thanks!
That they are :) *does cvs diff* , this one is much less important
(in fact the only thing actually wrong in the doc is the paths),
but I'll resubmit it anyway:
Index: manual/suexec.html.en
===================================================================
RCS file: /home/cvspublic/httpd-2.0/docs/manual/suexec.html.en,v
retrieving revision 1.47
diff -u -r1.47 suexec.html.en
--- manual/suexec.html.en 25 Jul 2003 18:31:25 -0000 1.47
+++ manual/suexec.html.en 1 Sep 2003 12:01:47 -0000
@@ -124,6 +124,16 @@
<ol>
<li>
+ <strong>Is the user executing this wrapper a valid user of
+ this system?</strong>
+
+ <p class="indent">
+ This is to ensure that the user executing the wrapper is
+ truly a user of the system.
+ </p>
+ </li>
+
+ <li>
<strong>Was the wrapper called with the proper number of
arguments?</strong>
@@ -138,16 +148,6 @@
</li>
<li>
- <strong>Is the user executing this wrapper a valid user of
- this system?</strong>
-
- <p class="indent">
- This is to ensure that the user executing the wrapper is
- truly a user of the system.
- </p>
- </li>
-
- <li>
<strong>Is this valid user allowed to run the
wrapper?</strong>
@@ -244,11 +244,12 @@
</li>
<li>
- <strong>Does the directory in which the target CGI/SSI program
- resides exist?</strong>
+ <strong>Can we change directory to the one in which the target CGI/SSI program
+ resides?</strong>
<p class="indent">
- If it doesn't exist, it can't very well contain files.
+ If it doesn't exist, it can't very well contain files. If we can't
+ change directory to it, it might aswell not exist.
</p>
</li>
@@ -443,10 +444,10 @@
<div class="example"><p><code>
suEXEC setup:<br />
- suexec binary: /usr/local/apache/sbin/suexec<br />
- document root: /usr/local/apache/share/htdocs<br />
+ suexec binary: /usr/local/apache2/sbin/suexec<br />
+ document root: /usr/local/apache2/share/htdocs<br />
userdir suffix: public_html<br />
- logfile: /usr/local/apache/var/log/suexec_log<br />
+ logfile: /usr/local/apache2/var/log/suexec_log<br />
safe path: /usr/local/bin:/usr/bin:/bin<br />
caller ID: www<br />
minimum user ID: 100<br />
@@ -463,13 +464,40 @@
command "make install" to install them. The binary image
"suexec" is installed in the directory defined by the --sbindir
option. Default location is
- "/usr/local/apache/sbin/suexec".<br />
+ "/usr/local/apache2/sbin/suexec".<br />
Please note that you need <strong><em>root
privileges</em></strong> for the installation step. In order
for the wrapper to set the user ID, it must be installed as
owner <code><em>root</em></code> and must have the setuserid
execution bit set for file modes.</p>
+ <p><strong>Setting paranoid permissions</strong><br />
+ Allthough the suexec wrapper will check to ensure that its
+ caller is the correct user as specified with the
+ "--with-suexec-caller" configure option, there is always the
+ possiblity that a system or library call suexec uses before
+ this check may be exploitable on your system. To counter this,
+ and because it is best-practise in general, you should use
+ filesystem permissions to ensure that only the group apache
+ runs as may execute suexec.</p>
+
+ <p>If for example, your webserver is configured to run as;</p>
+
+<div class="example"><p><code>
+ User www<br />
+ Group webgroup<br />
+</code></p></div>
+
+ <p>and suexec is installed at "/usr/local/apache2/sbin/suexec", you
+ should run:</p>
+
+<div class="example"><p><code>
+ chgrp webgroup /usr/local/apache2/bin/suexec<br />
+ chmod 4750 /usr/local/apache2/bin/suexec<br />
+</code></p></div>
+
+ <p>This will ensure that only the group apache runs as can even
+ execute the suexec wrapper.</p>
</div><div class="top"><a href="#page-header"><img alt="top" src="./images/up.gif" /></a></div>
<div class="section">
<h2><a name="enable" id="enable">Enabling & Disabling
Index: manual/suexec.xml
===================================================================
RCS file: /home/cvspublic/httpd-2.0/docs/manual/suexec.xml,v
retrieving revision 1.9
diff -u -r1.9 suexec.xml
--- manual/suexec.xml 25 Jul 2003 18:31:25 -0000 1.9
+++ manual/suexec.xml 1 Sep 2003 12:01:47 -0000
@@ -96,6 +96,16 @@
<ol>
<li>
+ <strong>Is the user executing this wrapper a valid user of
+ this system?</strong>
+
+ <p class="indent">
+ This is to ensure that the user executing the wrapper is
+ truly a user of the system.
+ </p>
+ </li>
+
+ <li>
<strong>Was the wrapper called with the proper number of
arguments?</strong>
@@ -110,16 +120,6 @@
</li>
<li>
- <strong>Is the user executing this wrapper a valid user of
- this system?</strong>
-
- <p class="indent">
- This is to ensure that the user executing the wrapper is
- truly a user of the system.
- </p>
- </li>
-
- <li>
<strong>Is this valid user allowed to run the
wrapper?</strong>
@@ -216,11 +216,12 @@
</li>
<li>
- <strong>Does the directory in which the target CGI/SSI program
- resides exist?</strong>
+ <strong>Can we change directory to the one in which the target CGI/SSI program
+ resides?</strong>
<p class="indent">
- If it doesn't exist, it can't very well contain files.
+ If it doesn't exist, it can't very well contain files. If we can't
+ change directory to it, it might aswell not exist.
</p>
</li>
@@ -416,10 +417,10 @@
<example>
suEXEC setup:<br />
- suexec binary: /usr/local/apache/sbin/suexec<br />
- document root: /usr/local/apache/share/htdocs<br />
+ suexec binary: /usr/local/apache2/sbin/suexec<br />
+ document root: /usr/local/apache2/share/htdocs<br />
userdir suffix: public_html<br />
- logfile: /usr/local/apache/var/log/suexec_log<br />
+ logfile: /usr/local/apache2/var/log/suexec_log<br />
safe path: /usr/local/bin:/usr/bin:/bin<br />
caller ID: www<br />
minimum user ID: 100<br />
@@ -436,13 +437,40 @@
command "make install" to install them. The binary image
"suexec" is installed in the directory defined by the --sbindir
option. Default location is
- "/usr/local/apache/sbin/suexec".<br />
+ "/usr/local/apache2/sbin/suexec".<br />
Please note that you need <strong><em>root
privileges</em></strong> for the installation step. In order
for the wrapper to set the user ID, it must be installed as
owner <code><em>root</em></code> and must have the setuserid
execution bit set for file modes.</p>
+ <p><strong>Setting paranoid permissions</strong><br />
+ Allthough the suexec wrapper will check to ensure that its
+ caller is the correct user as specified with the
+ "--with-suexec-caller" configure option, there is always the
+ possiblity that a system or library call suexec uses before
+ this check may be exploitable on your system. To counter this,
+ and because it is best-practise in general, you should use
+ filesystem permissions to ensure that only the group apache
+ runs as may execute suexec.</p>
+
+ <p>If for example, your webserver is configured to run as;</p>
+
+<example>
+ User www<br />
+ Group webgroup<br />
+</example>
+
+ <p>and suexec is installed at "/usr/local/apache2/sbin/suexec", you
+ should run:</p>
+
+<example>
+ chgrp webgroup /usr/local/apache2/bin/suexec<br />
+ chmod 4750 /usr/local/apache2/bin/suexec<br />
+</example>
+
+ <p>This will ensure that only the group apache runs as can even
+ execute the suexec wrapper.</p>
</section>
<section id="enable"><title>Enabling & Disabling
--
Colm MacCárthaigh Public Key: colm+pgp@stdlib.net
colm@stdlib.net http://www.stdlib.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org
Re: [PATCH] [resend] [colm@stdlib.net IPv6 changes in bind.xml]
Posted by Colm MacCarthaigh <co...@stdlib.net>.
On Sun, Sep 28, 2003 at 03:03:30PM -0400, Cliff Woolley wrote:
> On Sun, 28 Sep 2003, Colm MacCarthaigh wrote:
>
> > > The resends are not a bother. :) Should this change go in both 2.0 and
> > > 2.1 or just 2.1? I don't happen to remember whether the change it goes
> > > with was backported or not.
> >
> > sorry, just 2.1 :)
>
> Okay, that's what I did. So AFAIK all the patches you've (re)submitted
> are now committed to the right branches... thanks!
That they are :) *does cvs diff* , this one is much less important
(in fact the only thing actually wrong in the doc is the paths),
but I'll resubmit it anyway:
Index: manual/suexec.html.en
===================================================================
RCS file: /home/cvspublic/httpd-2.0/docs/manual/suexec.html.en,v
retrieving revision 1.47
diff -u -r1.47 suexec.html.en
--- manual/suexec.html.en 25 Jul 2003 18:31:25 -0000 1.47
+++ manual/suexec.html.en 1 Sep 2003 12:01:47 -0000
@@ -124,6 +124,16 @@
<ol>
<li>
+ <strong>Is the user executing this wrapper a valid user of
+ this system?</strong>
+
+ <p class="indent">
+ This is to ensure that the user executing the wrapper is
+ truly a user of the system.
+ </p>
+ </li>
+
+ <li>
<strong>Was the wrapper called with the proper number of
arguments?</strong>
@@ -138,16 +148,6 @@
</li>
<li>
- <strong>Is the user executing this wrapper a valid user of
- this system?</strong>
-
- <p class="indent">
- This is to ensure that the user executing the wrapper is
- truly a user of the system.
- </p>
- </li>
-
- <li>
<strong>Is this valid user allowed to run the
wrapper?</strong>
@@ -244,11 +244,12 @@
</li>
<li>
- <strong>Does the directory in which the target CGI/SSI program
- resides exist?</strong>
+ <strong>Can we change directory to the one in which the target CGI/SSI program
+ resides?</strong>
<p class="indent">
- If it doesn't exist, it can't very well contain files.
+ If it doesn't exist, it can't very well contain files. If we can't
+ change directory to it, it might aswell not exist.
</p>
</li>
@@ -443,10 +444,10 @@
<div class="example"><p><code>
suEXEC setup:<br />
- suexec binary: /usr/local/apache/sbin/suexec<br />
- document root: /usr/local/apache/share/htdocs<br />
+ suexec binary: /usr/local/apache2/sbin/suexec<br />
+ document root: /usr/local/apache2/share/htdocs<br />
userdir suffix: public_html<br />
- logfile: /usr/local/apache/var/log/suexec_log<br />
+ logfile: /usr/local/apache2/var/log/suexec_log<br />
safe path: /usr/local/bin:/usr/bin:/bin<br />
caller ID: www<br />
minimum user ID: 100<br />
@@ -463,13 +464,40 @@
command "make install" to install them. The binary image
"suexec" is installed in the directory defined by the --sbindir
option. Default location is
- "/usr/local/apache/sbin/suexec".<br />
+ "/usr/local/apache2/sbin/suexec".<br />
Please note that you need <strong><em>root
privileges</em></strong> for the installation step. In order
for the wrapper to set the user ID, it must be installed as
owner <code><em>root</em></code> and must have the setuserid
execution bit set for file modes.</p>
+ <p><strong>Setting paranoid permissions</strong><br />
+ Allthough the suexec wrapper will check to ensure that its
+ caller is the correct user as specified with the
+ "--with-suexec-caller" configure option, there is always the
+ possiblity that a system or library call suexec uses before
+ this check may be exploitable on your system. To counter this,
+ and because it is best-practise in general, you should use
+ filesystem permissions to ensure that only the group apache
+ runs as may execute suexec.</p>
+
+ <p>If for example, your webserver is configured to run as;</p>
+
+<div class="example"><p><code>
+ User www<br />
+ Group webgroup<br />
+</code></p></div>
+
+ <p>and suexec is installed at "/usr/local/apache2/sbin/suexec", you
+ should run:</p>
+
+<div class="example"><p><code>
+ chgrp webgroup /usr/local/apache2/bin/suexec<br />
+ chmod 4750 /usr/local/apache2/bin/suexec<br />
+</code></p></div>
+
+ <p>This will ensure that only the group apache runs as can even
+ execute the suexec wrapper.</p>
</div><div class="top"><a href="#page-header"><img alt="top" src="./images/up.gif" /></a></div>
<div class="section">
<h2><a name="enable" id="enable">Enabling & Disabling
Index: manual/suexec.xml
===================================================================
RCS file: /home/cvspublic/httpd-2.0/docs/manual/suexec.xml,v
retrieving revision 1.9
diff -u -r1.9 suexec.xml
--- manual/suexec.xml 25 Jul 2003 18:31:25 -0000 1.9
+++ manual/suexec.xml 1 Sep 2003 12:01:47 -0000
@@ -96,6 +96,16 @@
<ol>
<li>
+ <strong>Is the user executing this wrapper a valid user of
+ this system?</strong>
+
+ <p class="indent">
+ This is to ensure that the user executing the wrapper is
+ truly a user of the system.
+ </p>
+ </li>
+
+ <li>
<strong>Was the wrapper called with the proper number of
arguments?</strong>
@@ -110,16 +120,6 @@
</li>
<li>
- <strong>Is the user executing this wrapper a valid user of
- this system?</strong>
-
- <p class="indent">
- This is to ensure that the user executing the wrapper is
- truly a user of the system.
- </p>
- </li>
-
- <li>
<strong>Is this valid user allowed to run the
wrapper?</strong>
@@ -216,11 +216,12 @@
</li>
<li>
- <strong>Does the directory in which the target CGI/SSI program
- resides exist?</strong>
+ <strong>Can we change directory to the one in which the target CGI/SSI program
+ resides?</strong>
<p class="indent">
- If it doesn't exist, it can't very well contain files.
+ If it doesn't exist, it can't very well contain files. If we can't
+ change directory to it, it might aswell not exist.
</p>
</li>
@@ -416,10 +417,10 @@
<example>
suEXEC setup:<br />
- suexec binary: /usr/local/apache/sbin/suexec<br />
- document root: /usr/local/apache/share/htdocs<br />
+ suexec binary: /usr/local/apache2/sbin/suexec<br />
+ document root: /usr/local/apache2/share/htdocs<br />
userdir suffix: public_html<br />
- logfile: /usr/local/apache/var/log/suexec_log<br />
+ logfile: /usr/local/apache2/var/log/suexec_log<br />
safe path: /usr/local/bin:/usr/bin:/bin<br />
caller ID: www<br />
minimum user ID: 100<br />
@@ -436,13 +437,40 @@
command "make install" to install them. The binary image
"suexec" is installed in the directory defined by the --sbindir
option. Default location is
- "/usr/local/apache/sbin/suexec".<br />
+ "/usr/local/apache2/sbin/suexec".<br />
Please note that you need <strong><em>root
privileges</em></strong> for the installation step. In order
for the wrapper to set the user ID, it must be installed as
owner <code><em>root</em></code> and must have the setuserid
execution bit set for file modes.</p>
+ <p><strong>Setting paranoid permissions</strong><br />
+ Allthough the suexec wrapper will check to ensure that its
+ caller is the correct user as specified with the
+ "--with-suexec-caller" configure option, there is always the
+ possiblity that a system or library call suexec uses before
+ this check may be exploitable on your system. To counter this,
+ and because it is best-practise in general, you should use
+ filesystem permissions to ensure that only the group apache
+ runs as may execute suexec.</p>
+
+ <p>If for example, your webserver is configured to run as;</p>
+
+<example>
+ User www<br />
+ Group webgroup<br />
+</example>
+
+ <p>and suexec is installed at "/usr/local/apache2/sbin/suexec", you
+ should run:</p>
+
+<example>
+ chgrp webgroup /usr/local/apache2/bin/suexec<br />
+ chmod 4750 /usr/local/apache2/bin/suexec<br />
+</example>
+
+ <p>This will ensure that only the group apache runs as can even
+ execute the suexec wrapper.</p>
</section>
<section id="enable"><title>Enabling & Disabling
--
Colm MacCárthaigh Public Key: colm+pgp@stdlib.net
colm@stdlib.net http://www.stdlib.net/
Re: [PATCH] [resend] [colm@stdlib.net IPv6 changes in bind.xml]
Posted by Cliff Woolley <jw...@virginia.edu>.
On Sun, 28 Sep 2003, Colm MacCarthaigh wrote:
> > The resends are not a bother. :) Should this change go in both 2.0 and
> > 2.1 or just 2.1? I don't happen to remember whether the change it goes
> > with was backported or not.
>
> sorry, just 2.1 :)
Okay, that's what I did. So AFAIK all the patches you've (re)submitted
are now committed to the right branches... thanks!
--Cliff
Re: [PATCH] [resend] [colm@stdlib.net IPv6 changes in bind.xml]
Posted by Cliff Woolley <jw...@virginia.edu>.
On Sun, 28 Sep 2003, Colm MacCarthaigh wrote:
> > The resends are not a bother. :) Should this change go in both 2.0 and
> > 2.1 or just 2.1? I don't happen to remember whether the change it goes
> > with was backported or not.
>
> sorry, just 2.1 :)
Okay, that's what I did. So AFAIK all the patches you've (re)submitted
are now committed to the right branches... thanks!
--Cliff
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org
Re: [PATCH] [resend] [colm@stdlib.net IPv6 changes in bind.xml]
Posted by Colm MacCarthaigh <co...@stdlib.net>.
On Sun, Sep 28, 2003 at 12:24:43PM -0400, Cliff Woolley wrote:
> On Sun, 28 Sep 2003, Colm MacCarthaigh wrote:
>
> > While I'm at it; Rather than bother the list with resends, is it (or
> > would it be more) appropriate to open a wishlist/feature req bug for
> > documentation changes ?
>
> The resends are not a bother. :) Should this change go in both 2.0 and
> 2.1 or just 2.1? I don't happen to remember whether the change it goes
> with was backported or not.
sorry, just 2.1 :)
--
Colm MacCárthaigh Public Key: colm+pgp@stdlib.net
colm@stdlib.net http://www.stdlib.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org
Re: [PATCH] [resend] [colm@stdlib.net IPv6 changes in bind.xml]
Posted by Cliff Woolley <jw...@virginia.edu>.
On Sun, 28 Sep 2003, Colm MacCarthaigh wrote:
> While I'm at it; Rather than bother the list with resends, is it (or
> would it be more) appropriate to open a wishlist/feature req bug for
> documentation changes ?
The resends are not a bother. :) Should this change go in both 2.0 and
2.1 or just 2.1? I don't happen to remember whether the change it goes
with was backported or not.
--Cliff
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org